Open Community-Based Crowdsourcing Geoportal for Earth Observation Products: A Model Design and Prototype Implementation

Abstract

Over the past few decades, geoportals have been considered as the key technological solutions for easy access to Earth observation (EO) products, and the implementation of spatial data infrastructure (SDI). However, less attention has been paid to developing an efficient model for crowdsourcing EO products through geoportals. To this end, a new model called the “Open Community-Based Crowdsourcing Geoportal for Earth Observation Products” (OCCGEOP) was proposed in this study. The model was developed based on the concepts of volunteered geographic information (VGI) and community-based geoportals using the latest open technological solutions. The key contribution lies in the conceptualization of the frameworks for automated publishing of standard map services such as the Web Map Service (WMS) and the Web Coverage Service (WCS) from heterogeneous EO products prepared by volunteers as well as the communication portion to request voluntary publication of the map services and giving feedback for quality assessment and assurance. To evaluate the feasibility and performance of the proposed model, a prototype implementation was carried out by conducting a pilot study in Iran. The results showed that the OCCGEOP is compatible with the priorities of the new generations of geoportals, having some unique features and promising performance.

1. Introduction

Efficient management, use, and sharing of geographic information is integral to the achievement of good governance and sustainable development objectives and brings significant economic, social, and environmental benefits to the countries. Over the past few decades, the concept of geoportals has emerged as one of the key technological solutions for improving the efficiency and effectiveness of geospatial activities. The geoportal allows the data consumers to access, search and discover geospatial data and enables data producers to publish and share geospatial data. Furthermore, this online infrastructure may provide other geographic information services such as data visualization, editing, and analysis to its various stakeholders [1,2]. The geospatial data are distributed and made available by the different data producers using a variety of technologies and formats. In this term, the geoportal provides effective solutions to the geospatial data interoperability; it facilitates the multi-source data integration and enables the stakeholders to access the geospatial information and maps in the standard formats [3]. The geoportals connect the geospatial data producers and consumers directly and improve collaboration and cooperation among the various stakeholders, leverage existing geospatial resources, and ease the finding of relevant geospatial products; hence, it plays a key role in preventing duplicated efforts, inconsistencies, delays, and wasted time and resources [4]. The geoportal is one of the key components that are needed for establishing spatial data infrastructure (SDI) [5]. It is considered as the most visible part of SDI and the entry point to it [6,7]. Due to the key functions and unique characteristics, and high demand for Earth observation (EO) products (raw and processed imagery), along with the general-purpose geoportals, the specialized geoportals have been designed and implemented exclusively for EO products [8,9,10].

Crowdsourcing [11] is an increasingly common means of obtaining of geospatial data in recent years as it can provide large volumes of low-cost, and up-to-date open geospatial data over large geographical extents in a short period [12,13,14]. This concept has been successfully used over the last 10 years in the new generation of online spatio-temporal mapping and monitoring projects in the various areas such as land use/land cover mapping projects (e.g., OpenStreetMap, Mapillary and Geo-Wiki), biodiversity mapping and monitoring projects (e.g., iNaturalist and eBird), and damage, hazard mapping and monitoring projects (e.g., Humanitarian OpenStreetMap and Did You Feel It?), and pollution mapping and monitoring projects (e.g., NoiseTube and Safecast) [15,16,17,18].

Most of the previous studies that aimed to blend the concept of crowdsourcing with airborne, and space-borne remote sensing (hereafter remote sensing) have mainly been focused on (1) providing crowdsourced ground truth samples to be used in training and validation steps of image classification, (2) using the crowdsourcing technique for geotagging and visual interpretation of remotely-sensed imagery, and (3) exploiting volunteers’ power for manual modification and enhancement of the formal classification results [12,17,19,20]. A relatively small body of literature (e.g., [21,22,23,24,25,26,27,28]) has discussed the potential, application, and different dimensions of using the crowdsourcing technique for producing EO products.

By the rise of the citizen science [29] paradigm in the domain of remote sensing, the rapid increase in the availability of low-cost sensors and remote sensing platforms, and the growth of open data, free and open-source software solutions, and free and open training courses in recent years, a considerable volume of crowdsourced EO products have been produced by volunteers over recent years that have traditionally been produced by professionals. In this context, the deployment of inexpensive platforms, including unmanned aerial vehicles (UAV), balloons, and kites equipped with low-cost sensors for voluntary acquisition of EO data, has been increasingly prevalent [21]. Moreover, following a growth in the number of do-it-yourself (DIY) small satellite (e.g., DIY picosatellite) missions [30], the new citizen science applications for these relatively low-cost platforms, such as voluntary remote sensing, are gradually emerging. Similarly, over the past years, the light aircrafts equipped with cameras have been used as volunteer pilots for the voluntary acquisition of EO data [23]. The crowdsourced raw EO products that are collected through the voluntary remote sensing projects are partially openly shared through the few existing online platforms designed for hosting openly licensed remotely-sensed imagery (e.g., OpenAerialMap) [21,31]. Alongside the rise in production of the raw EO products, the increasing availability of open remotely-sensed data produced by volunteers and as well as professional EO data producers [32], free and open-source geospatial software, and free and open geospatial education, and the growth in the number and processing power of personal computing devices over the past few years have facilitated image processing tasks for the volunteers and have enabled them to produce various voluntary processed EO products according to their levels of expertise.

Some previous contributions have studied the different dimensions of the integration of volunteered geographical information (VGI) [33] or Web 2.0 [34] paradigm in SDI and geoportals to study the various advantages and features of them (e.g., [7,35,36,37,38,39,40,41]). However, until now, less attention has been paid to the development of geoportal models for hosting VGI—particularly the crowdsourced EO products. In this context, to the best of our knowledge, so far, no model has been proposed in the existing literature (especially those specifically developed for serving EO products) to provide the technological solutions for (1) supporting volunteer EO product providers to provide map services in accordance with the SDI interoperability standards, and (2) facilitating the communication between geoportal users (and facilitating the ordering of voluntary EO products, and control of their quality) simultaneously.

In this research, a schema for geoportals named “Open Community-Based Crowdsourcing Geoportal for Earth Observation Products” (OCCGEOP) was introduced. Furthermore, a prototype implementation of the proposed model was developed for crowdsourcing EO products, and then to test the prototype system, a pilot study was conducted in Iran. The proposed model was designed in compliance with open-source solutions and Open Geospatial Consortium (OGC) standard services. In the proposed model for our geoportal, the crowdsourcing concept plays a major role, meaning that the volunteers may share their EO products with others via standard structures and formats. The proposed model exploits the civic participation and integrates social community capabilities and local knowledge of volunteers into geoportal architecture to facilitate the user-to-user communication and directs and coordinates the production, sharing, and accessing of voluntary EO data in the geoportal. In this context, the main contributions of this study are (1) the conceptualization of an open SDI geoportal for voluntary earth observation products in a community-based setting, and (2) designing a model for the proposed concept and implementing a prototype for the developed model for the first time.

The remainder of this paper is organized as follows: Section 2 presents the related works to this research. Section 3 describes the features and properties of OCCGEOP. Section 4 proposes the architecture for OCCGEOP and presents the prototype implementation of OCCGEOP. Section 5 provides some results from the implemented OCCGEOP prototype system. Section 6 discusses the advantages, features and capabilities of OCCGEOP and evaluates the opinions and preferences of OCCGEOP’s expert and practitioner users about them. Finally, the last section is reserved for the conclusion and provides some recommendations for future work.

2. Related Works

The first contributions on geoportals and explanations of its principles were carried out through the development of the United States national spatial data infrastructure (NSDI) in 1994 [42]. The development of the earliest major geoportal, the NSDI clearinghouse network, was organized by the United States Federal Geographic Data Committee (FGDC) [43]. NSDI clearinghouse network is now a distributed system of Internet-based agency servers containing field-level metadata of digital spatial data and searchable catalogs as well as available applications, and services. In 2003, the Geospatial One-Stop (GOS) geoportal was developed as part of the United States e-Government initiative [1]. GOS aimed to promote geospatial data collection and maintenance coordination and alignment across all levels of government [44]. One of the advantages of GOS over the NSDI clearinghouse network was that a web-based geoportal interface in GOS made it possible for users to be connected to data providers [45]. The GOS user may communicate with the system via a simple web browser (thin client) or a geographic information system (GIS) application (thick client). One of the most efficient examples of geoportals that extended the feature of sharing geographic information based on region or theme is the Infrastructure for Spatial Information in the European Community (INSPIRE) geoportal. INSPIRE was developed in 2007 to facilitate spatial or geographical information accessibility and interoperability for a wide range of sustainable development purposes in Europe [46]. Currently, many countries have taken fundamental steps in the development of geoportals at the national level [2]. Modern web-based geoportals such as NASA’s Earth Observing System Data and Information System (EOSDIS) include direct access to raw data in different formats from various resources, such as satellites, aircrafts, field measurements, full metadata, and visual tools to interact with data on online maps [47]. In addition, the geoportals have been designed to be used in many other fields and applications such as agriculture, disaster management and early warning, land and water management, urban planning, air quality, and energy [2,48,49,50,51,52,53,54].

The main direction of studies on modern geoportals is now to provide effective ways to handle big data, develop web services shared with different parties, and application programming interfaces (APIs) for developers and the end-users [55,56]. De Longueville [7] discussed the possible strategies for the development of the new generation of geoportals including the facilitation of the user-to-user communication (for sharing of users’ common interests and needs) and dataset and map sharing based on users requests and establishing a ranking mechanism to create “the most popular data” listings for geoportals.

The coordinated series of agreements on technology standards, institutional arrangements, and policies within an SDI provide an interactive connection of geospatial data, metadata, users, and resources, which can appear in a geoportal [57]. In this sense, the main advantage of this infrastructure is the sharing of spatial data produced by various public and private organizations in accordance with defined standards [58]. Currently, OGC and the International Organization for Standardization (ISO) have played a key role in standardizing web-based geospatial data and services to make them interoperable [59]. OGC provides the best open solutions and standards for achieving the geospatial data interoperability by providing a comprehensive framework of services and models [60]. Some OGC standard services such as Web Coverage Service (WCS), the Web Map Service (WMS), the Web Feature Service (WFS), and the Catalog Service for Web (CSW) have been frequently used in the design of geoportal architectures [61,62]. Service metadata can also be published based on standards such as ISO19115 and ISO19139 [63].

Among recent studies on geoportals, Granell et al. [64] presented a conceptual architecture and service-oriented implementation of a regional geoportal. Using their developed geoportal, they specifically focused on unified monitoring of rice crop at a regional scale. Iosifescu-Enescu et al. [65] proposed a cloud-based architecture for a Swiss academic geoportal so-called Geodata Versatile Information Transfer environment (GeoVITe). They discussed that the cloudification mechanism has a major impact on making the geoportals scalable on-demand. Furthermore, they discussed that the use of public clouds reduces the upfront costs of conventional computing infrastructures. Dareshiri et al. [66] have developed a recommender geoportal to enhance the functionalities of traditional geoportals. The proposed framework is able to evaluate the behaviors of users and suggest geospatial resources to the geoportal users according to their desires and preferences. Kadochnikov et al. [67] developed a real-time geoportal for air pollution and meteorological data monitoring. To create this system, they adopted mechanisms to provide real-time geospatial data as OGC web map service standards.

3. Features and Properties of OCCGEOP Model

The general workflow of the proposed OCCGEOP model for coordination, sharing, publishing, standardization, searching and discovery, and accessing of the voluntary EO products as well as facilitating users’ communication, giving feedback, and rating published products, and management and maintenance of the proposed system have been depicted in Figure 1. In the proposed system, the volunteers (whose skills and competence were approved by the administrators of the system) are able to share their original EO products on the geoportal. All the users (data consumers) are able to use the system to search for volunteers as well as to search and discover map services using the generated data catalogs (published in standard CSW form in the geoportal) for the crowdsourced map services and access the generated standard crowdsourced map services (published in standard WMS and WCS forms in the geoportal). If an end-user needs a map service that has not been shared and published in the system, he/she can send his/her request to the volunteers for the production and sharing of his/her requested EO product. Furthermore, a user is able to give feedback on the contributions of volunteers and ratings of their shared EO products (more details about the workflow of the proposed model and its components will be provided in the following sections).

The main features that have been taken into account in our proposal for the OCCGEOP model could be categorized into seven major areas and research lines (Figure 2). Some of these features are also available in some of the existing contemporary geoportals and do not show much difference at least in the concept; however, some features of OCCGEOP are novel and were designed consistent with the features and goals of new generations of geoportals. In Section 3.1, Section 3.2, Section 3.3, Section 3.4, Section 3.5, Section 3.6 and Section 3.7, the main features and properties of OCCGEOP will be introduced and discussed briefly.

3.1. Accordance with OGC Standards

OGC standards are developed to render discoverable, accessible, interoperable, and reusable location information and services. The OCCGEOP, as one of its goals, has considered in its plan homogenizing the heterogeneous crowdsourced EO products (in formats and themes) via interoperable and reusable standard OGC map services such as WMS and WCS as well as being discoverable through standard metadata services. This is consistent with the priorities of many modern geoportals where they concentrate on interoperability by implementing standards for the exploration and use of geographic data and services. As OCCGEOP is developed in accordance with OGC standards, GIS specialists and software developers can easily use the standard EO data of OCCGEOP with other open, interoperable, and reusable geospatial resources and integrate it in other standard interfaces and web-based GIS platforms.

3.2. Data Quality Control and Volunteer Engagement Mechanisms

The core of the OCCGEOP model is the crowdsourcing concept. Although VGI can potentially be used in different scientific research and practical projects, concerns over the quality of the crowdsourced data may remain as a barrier to its adoption by the data consumer [17,68,69]. Therefore, the assessment and assurance of VGI quality may reduce the concerns of the consumers of such data. The OCCGEOP users who do not want to share data in the system do not need to be authenticated. However, to reduce the aforementioned concerns, only the verified users can serve as the providers of crowdsourced EO products in OCCGEOP. In this term, upon the initial registration of a user who requested to take the data provider role in OCCGEOP, the administrators of OCCGEOP conduct a basic screening of the qualifications and experience of the user based on the information provided by the user in the online registration form. Then, if the qualifications and experience of the user meet the minimum requirements defined for data providers, the role of the user is promoted to the data provider role and a permit is granted to the user to access the tools for the generation of the new map service. In this basic approach for reducing the chance of sharing poor quality user-generated content [70] over the geoportal, it is assumed that a user with higher levels of self-declared skill and expertise in a particular area generally can produce a higher quality data in that area compared to the users with lower levels of skill and expertise [68,71]. This basic quality assurance approach has been used successfully in some other projects that deal with user-contributed information. The ratings and comments of other users on a crowdsourced geospatial product can serve as a proxy indicator for the quality of the product [68,72]. In this sense, the OCCGEOP model uses a star ranking mechanism for ranking a shared EO product in addition to the comments feature that enables the users to post their comments on a product. The indicators of data producers’ provenance and reputation have been used in previous studies and projects to quantify the quality of the data [68,73]. The OCCGEOP model also uses a mechanism for ranking a provider of crowdsourced EO products using average star ratings (the feedbacks given by other users) and contribution history for his/her previous shared products. The computed score for a provider of a crowdsourced EO product through this mechanism can serve as an indicator for the trustworthiness level of the data provider and a proxy indicator for the quality of his/her shared products over the geoportal—including the products that have not been rated by other users yet.

Previous studies have emphasized the positive impact of recognition or reward (e.g., adding a score, token, or badge to users’ online profiles based on the quality or quantity of their previous contributions) on sustaining the engagement of the volunteers in the participatory and citizen science projects [74]. In this context, the estimated score for the data providers in OCCGEOP can help to retain the engagement of the volunteers in the geoportal and enhance the popularity of the application of it.

3.3. Automatic Conversion of User’s Products to Standard Services

Another goal of OCCGEOP is to provide embedded frameworks for automatically transforming heterogeneous user-generated EO products into standard services such as WMS and WCS. In most of the existing geoportals, there is no room for volunteers to present their geospatial products in the form of standard map services. Such activities are typically carried out by professional service providers and experienced mediators in geoportals. However, in the OCCGEOP design, the volunteers are able to share standard map services without engaging in a complicated process of publishing the services. In the OCCGEOP, the users can upload regular data formats such as GeoTIFFs or Shapefiles and use the automated mechanisms to transfer them into the standard map services on the GIS server and share them with other users. Such a functionality can lead to the realization of a crowdsourced geoportal.

3.4. Communication between Users

The organization of user communities is in line with the vision of the next generation of geoportals. In OCCGEOP, the users are enabled to request their desired product by exchanging messages within the system. The volunteer who receives the message can create the map service based on their expertise and then publish it. In OCCGEOP, a user’s profile and related descriptions about specialties and capabilities of him/her, as well as the previously produced map services in the system, can be seen by other users. A user can interact with other users and their actions through giving feedback (comments) on the contributions of other users and rating of their products. Using the query features in OCCGEOP, individuals can also be aware of their community’s geographic area of interest, subject and type of EO products, and the situation of constantly growing user-generated content.

3.5. Dynamic Web Page

A dynamic web page can display different content each time it is viewed in response to different contexts or conditions [75]. Using state-of-the-art technologies, dynamic and interactive web pages make a request to the server, interpret the data, and refresh the current screen in such a way that the user never knows that something had ever been sent to the server. As with many other geoportals, the interactive map component as well as the communication components for exchanging messages or scoring web services have been designated in OCCGEOP based on dynamic web page technologies. As the important Web 2.0 technologies, Asynchronous JavaScript and XML (AJAX) programming use JavaScript and the Document Object Model (DOM) to update selected regions of the page area without undergoing a full page reload. Using this method in OCCGEOP will result in a faster, more interactive, and more communicative geoportal.

3.6. Search and Discovery of Data and Volunteers

A common feature in all geoportals, as in OCCGEOP, is the search and discovery of geospatial information based on metadata such as products’ bounding box, time limits, and other descriptions such as accuracy, spatial resolution of the products. In the OCCGEOP model, upon conducting a search and discovery, the service details (e.g., EO product thumbnail, an overview of the map, download link, and most importantly, the standard map service parameters) are provided for the user. Using the so-called standard map service parameters such as hostname, type of service, category name, and service name, etc., an EO product is easily reusable in another web-based GIS as an online geospatial layer. It is worth noting that the search and exploration capability in OCCGEOP is not limited to geospatial data but also applies to volunteers, i.e., finding their profile and related products.

3.7. Resting on Open-Source Technologies

Full reliance on open-source modules and components either for dealing with geospatial data or for other parts of the client and server is one of the most important points in OCCGEOP. This not only minimizes the expenses of the initial implementation of OCCGEOP but also makes the modification of the source code and software development easier. For instance, as will be explained in the next section, OCCGEOP will use GeoServer technology as a GIS engine in the background to publish standard WMS and WCS. Using such a strategy, no one has to worry about purchasing multiple licenses for internal components of OCCGEOP and installing these components several times.

4. Proposed Architecture and Prototype Implementation of OCCGEOP

4.1. Design and Technologies

Figure 3 presents the three-tier system architecture and adopted technologies for OCCGEOP. The system architecture is designed and implemented based on the state-of-the-art open-source technologies and components, the main components of which are discussed in the following. The open-source software technologies include Bootstrap (a free and open-source CSS framework for responsive web front-end development), JQuery (a JavaScript library designed to simplify traversal and manipulation of the HTML Document Object Model (DOM) tree), OpenLayers (a JavaScript open-source library for displaying map data in web browsers), Django (a Python-based free and open-source web framework that follows the model–template–views architectural pattern), GeoServer (a Java-written open-source server enabling users to publish, process and modify geospatial data), and PostgreSQL (a free and open-source relational database management system).

The presentation tier offers interfaces for the front-end framework from which user interactions such as communication with others, content generation, retrieving, and visualization of data are handled. Web pages, menus, icons, and widgets were designed using HTML, CSS, and Bootstrap libraries. To provide dynamic capabilities such as collecting the comments and scores about published geospatial services, participating in polls, filtering EO products and volunteers, the various Web 2.0 technologies such as AJAX, JavaScript, and JQuery as well as interfaces for using and presenting online map services such as OpenLayers API were used in the presentation tier.

The logic tier contains the server-side web core framework and application server along with some specific applications, including the request of EO products, the discovery of data and volunteers, scores and feedback, and adding map service and metadata. This layer offers a business logic for service and data connectivity and allows communication between end-users and remote data and services. The core logic tier of the proposed architecture is based on one of the most efficient web frameworks, Django. Django is a framework for developing high-level web applications in Python. Therefore, the main server-side programming language in this architecture is Python. Django follows the structure of model–view–controller pattern (MVC). In an MVC model, the code for working with the database (i.e., model) and the controller or business logic, which are the main modules of the system in Python, and the parts related to the rendering responses to the user interface (i.e., view) are separated. For example, the visual representation and template of the system do not contain any information such as the database and data storage parameters, the layer corresponding to respond to user requests, and the caching information for later use. Each information is related to a separate section and, if necessary, each section can exchange information or send a request to other sections. The appearance (i.e., HTML tags) or site template is stored in separate files. The control section is also created and stored as Python modules. In this case, the programmer will deal with the control modules and the designer with the HTML tags. If the purpose is to use a database, there is no need to write SQL statements, but this can be addressed through the internal mechanisms of Django with Python statements that enable the retrieval of the data, and deleting, updating and inserting a new record.

The most important modules as business logic can be divided into main items, including the admin module for the accessibility of admin pages, models for database design, filters for creating filters in user queries, forms for developing web forms for cases such as creating a new map service, URLs to structure links in the application, and views to process user requests and display responses on the web. In the logic tier, the get and post requests from clients are responded to via the open-source Apache HTTP server. In addition, GeoServer, which is an open-source GIS server technology for sharing and publishing map services and can publish data from any major spatial data source using OGC standards, was adopted in OCCGEOP. The logic tier enables the users to upload EO products and automatically transfer them to OGC standards such as WMS and WCS, and eventually share it with others. The OGC Web Map Tile Service (WMTS) [59] is also provided because the caching function is already enabled by default in GeoServer. Therefore, to increase the performance, at the time of displaying maps on OpenLayers, the tile-based map presentation is called.

Volunteers can log into the system and have access to map service generation tools after registering in the system and being verified by the admin. Any published EO product by volunteers can then be discovered and accessed by the search subsystem. To upload the EO products by a volunteer, he/she is required to provide additional metadata information about the product such as additional description, time of acquisition of the base image, accuracy, sensor type, and geographical bounding rectangle of the product. The system supports popular geospatial data formats such as GeoTIFF, ArcGrid, and Shapefile for the input data. The system administrator can grant users access to upload geospatial data as well as delete or modify metadata. The administrator can also create a new category for EO products within the system.

The data tier focuses on databases, including user and volunteer data, map services, registered metadata, categories of EO products, reviews and ratings from users, and request messages. It supplies the logic layer and specific applications with data as well as information on data sources. The data tier also stores the source image files of volunteers’ provided EO products. Django’s default database, SQLite, was used in the programming phase of the data tier for this purpose, which will be replaced with PostgreSQL in the production phase. The proposed data model is linked to Django modules such as pycsw and GeoServer, where pycsw is an open-source server-side implementation of the CSW metadata standard (catalog service) written in Python. By using this technology, spatial metadata standards such as ISO 19115 and FGDC were provided in the proposed model.

4.2. Database Model

A data model developed for OCCGEOP has been demonstrated in Figure 4. The classes and details of this data model can be expanded as needed. The main classes in this data model are category, map service, user, user profile, request, and feedback.

Category class contains the properties of a group of EO products such as a unique identifier, name, number of views, and description of that category. A category can include multiple generated map services. A map service stores the various metadata elements in the database, such as service name, description, the acquisition time of the base image, bounding rectangle (minimum latitude, maximum latitude, minimum longitude, and maximum longitude), type of satellite and sensor, and spatial resolution of the layer. Metadata can also include other items such as the spatial reference system, the amount of cloud cover, and the accuracy measures for the data. In addition, information such as a unique identifier, number of views, average score, service parameters, and thumbnail picture for the service is provided with the EO product to the end-users. Each map service is essentially a subset of a category and is generated by one of the system’s volunteer data providers, and the relations between a map service and a category or map service and a user have been established with the aid of foreign keys to keep the database integrated. Basic user information contains a unique identifier, username, password, email address, phone number, and postal address. As mentioned previously, a data provider is ranked based on the average scores of his/her published EO products in the OCCGEOP model. Other details, including user expertise, profile image, and personal website, are listed in the user profile as assets in a one-to-one relationship with the user class. A user may send a request to another volunteer regarding the production and sharing of a required EO product. In this sense, the records about the request’s sender and recipient, as well as message content and associated time, are created based on the model’s request class. Finally, the feedback class is in charge of establishing the link between a user and a map service to record and reflect relevant feedback and comments.

4.3. Use Cases and Activities

A representation of the main types of users and their interaction with the OCCGEOP and the different use cases in which the users are involved has been illustrated in Figure 5. The principal types of users in OCCGEOP include registered users, anonymous users, and administrators.

All registered users are eligible to request EO services, search map services and other users, view map service details (e.g., preview the product on the map and view service metadata), score map service, and download resources or use services. As explained before, only the registered users whose competence has been approved can publish the EO product in the system. The anonymous or unregistered users can only search for map services, view map service details, and download resources or use services. The administrator is responsible for defining and adding new thematic categories, handling users and verifying them, controlling the resources, and other usual tasks such as monitoring the server status or creating the database backup.

Figure 6 presents the major activities in the OCCGEOP and the different decision paths that occur from a starting point to an ending point. For instance, a registered user can access one of several activities after logging into the system, namely advanced search, update profile, and/or search for users. If an eligible registered user aims to add a new map service, he/she must fill in the metadata elements, upload the EO product, and proceed to the automatic generation of a WMS or WCS service.

4.4. Implementation of a Prototype

A prototype implementation of OCCGEOP was performed based on the proposed architecture, the technology, database design, and the required capabilities presented in the form of an activity diagram in the previous section.

The main components and features of the implemented system are presented in Figure 7, Figure 8, Figure 9, Figure 10, Figure 11 and Figure 12. These figures demonstrate how the user interacts with the geoportal. Figure 7 shows the geoportal homepage, which displays the main menus before the user registers and logs into the system. Therefore, the menus only provide an advanced search for map services and a few general items. A public poll and a list of the most frequently visited map services are to the left of this webpage.

Figure 8 illustrates the advanced search function of this system based on user-defined bounding boxes, as well as some metadata such as map category, service descriptions, time limits, etc. The search results include a list of names of map services, a snippet of the descriptions, the thumbnail of crowdsourced EO data products, and a link to details of the service. It should be noted that in the prototype implementation, the confirmed registered users voluntarily published their self-produced processed EO products (e.g., spectral indices images).

Figure 9 displays the detailed information of a map service. Previewing the remote sensing product overlaid on the OpenStreetMap base map, service rating (using rating stars), metadata, name, and profile of the volunteer who has prepared the product, WMS or WCS service parameters for calling the service, as well as the product download link in GeoTIFF format, are all among the features that the detail page provides to users, both members, and nonmembers.

Figure 10 is a screenshot after logging into the system where some new menus are accessible for the registered volunteer. In this figure, the user is adding a new map service. As described in the OCCGEOP model overview, after filling out a descriptive form of metadata elements and uploading the EO product, the user triggers the automated creation of WMS and WCS standards from data. In this model, automated processes for the development of standard map services and pre-designed metadata input web forms help to preserve data homogeneity and interoperability.

Figure 11 shows the searching functionality for finding the members of the portal and the links to the members’ profile. Within a profile, the area of expertise of the volunteer and the EO products that the volunteer has published are presented.

Finally, Figure 12 shows the communication functionality of the OCCGEOP model, where a user can send request messages to other volunteers (e.g., for requesting EO products) or receive the request messages from other volunteers in the system.

The prototype implementation is now running experimentally on a Windows server temporarily available at http://78.38.208.204:8000. Python 3.4 and Django 1.10 were used for the development of this system. The Client URL (CURL) technology was used to convert the data to the standard formats on server-side and disseminate them through the GeoServer. The CURL commands, which run as a Python library, made it possible to make this data conversion possible through network protocols. The important note is that it takes a short time to convert data to standard map services, making it promising for providing a dynamic web portal. Restricting the data uploading and conversion mechanism in this way prevented heterogeneity in user-generated content.

5. Results

5.1. An Overview of Crowdsourced EO Products and Automatically Published Services via Prototype System

The proposed OCCGEOP model was generally developed for serving the crowdsourced raw and processed EO products in raster data format. The implemented prototype of this model was tested by conducting a pilot project for crowdsourcing EO products in Iran. In this sense, by using the OCCGEOP prototype system, a set of EO products was obtained through the crowdsourced approach from volunteers across the country. The crowdsourced data in the prototype system encompass both raw and processed EO products. The reviewing of the crowdsourced datasets has revealed that all of the shared raw EO products were acquired by the volunteers by employing the UAV-based optical sensors. Moreover, the crowdsourced processed EO products were voluntarily produced based on (1) the images acquired by the volunteers using UAV-based optical sensors and (2) the open images obtained by satellite-based optical and radar sensors. The crowdsourced processed EO products in the system were generated by volunteers using the different types of image processing techniques, including spectral indices calculation, supervised image classification, differential radar interferometry, and photogrammetry. The crowdsourced EO products in the experimental geoportal cover different thematic EO areas, including the environment, natural hazards, and urban mapping and monitoring as well as base mapping.

Figure 13 presents examples of the created standard map services using the crowdsourced EO products in the implemented prototype system. Figure 13a shows a shared very high resolution (VHR) image from a private garden in Mashhad, Iran, acquired by a UAV-based Canon EOS M3 sensor in 2020. Figure 13b presents a VHR digital terrain model (DTM) image for a rural area near Tangal-e Mazar village, Khorasan Province, Iran, produced based on the stereo images obtained by a UAV-based 1-inch 20MP CMOS sensor in 2020. According to the shared metadata for the product, the image was initially generated by the volunteer for a road construction project, and then he shared it voluntarily with the system.

Figure 13c,d illustrate a modified normalized difference water index (MNDWI) image and a temperature condition index (TCI) image for an area located in West Azerbaijan and West Azerbaijan Provinces, Iran. These EO products were produced using the images obtained by the Landsat 8 Operational Land Imager (OLI) sensor in 2017. After the sharing of the MNDWI image (Figure 13c) by the volunteer in the system, a user asked him if he could produce and provide the TCI image for the same study area. Upon this request, the volunteer shared a TCI image (Figure 13d) in the system. Figure 13e shows the classified image of a district in Tabriz, Iran. According to the metadata of the product, the image was produced by processing the data that were acquired through the Sentinel-2 Multi Spectral Instrument (MSI) sensor in 2019, using the support vector machine (SVM) classifier. The shared image contains seven classes (building, road, soil, tree, grass, crop, and water) with an overall accuracy of 81%. This processed EO product was shared by a volunteer via the system upon a request by a user of the system. Finally, Figure 13f presents an interferogram image for land surface displacement in an area in Kermanshah Province, Iran caused due to the 2017 Iran–Iraq earthquake. The product was generated by the processing of Sentinel-2 synthetic aperture radar (SAR) data (obtained in 2017) based on the differential radar interferometry technique.

As was mentioned in Section 4.4., the crowdsourced EO products can be downloaded directly from the implemented geoportal using the provided product’s download link. In addition, the implemented prototype can visualize the published maps in the web browsers via WMS standard (Figure 13). Furthermore, for the sake of geospatial data interoperability, a URL for the WMS layer can be generated in the following general format by appending the required parameters for the GetMap operation that are provided by the prototype system: (http://Hostname:port/geoserver/CategoryName/wms?service=WMS&version=1.1.0&request=GetMap&layers=CategoryName:ServiceName&OtherParameters). Similarly, the client has access to the WCS service by appending parameters for the GetCoverage operation to the service’s URL in the following format: (http://Hostname:port/geoserver/ows?service=WCS&version=2.0.0&request=GetCoverage&coverageId=CoverageId&OtherParameters). These capabilities are getting power from open technical solutions (including GeoServer technology and OGC data interoperability standards) and enable a user to simply and routinely import the EO product as a WMS (or a WCS) layer into their desktop GIS or Web GIS platforms (which support these capabilities) and view it using the provided URL. For example, Figure 14a demonstrates how a user (data consumer) add the WMS layer of a crowdsourced Normalized Difference Vegetation Index (NDVI) product (from an area located in West Azerbaijan and West Azerbaijan Provinces, Iran) that was published in OCCGEOP prototype to a GIS software (QGIS software). Basically, the metadata of an EO product are provided within the implemented prototype (Figure 9); however, the adopted OGC data interoperability standards in the implemented OCCGEOP also enable the user to access the service-level metadata via a web browser using different methods such as WMS GetCapabilities or WCS DescribeCoverage. For example, Figure 14b shows the service-level metadata for the WMS layer of a crowdsourced MNDWI product (for an area located in West Azerbaijan and West Azerbaijan Provinces, Iran) that was accessed through the WMS GetCapabilities method by a user. Similarly, the user also can invoke the WCS DescribeCoverage operation to request more information about the coverage of service, including the area occupied by the coverage, spatial reference system, information about its resolution, and available image bands.

5.2. Performance Analysis and Optimization of the Prototype System

One of the most important analyses in creating prototype systems is performance testing. This can lead the developer to produce the final product with the desired quality to serve the end-users. In this sense, the GTmetrix (http://gtmetrix.com), a free tool to easily test the performance by crawling the web data, was used. This tool could analyze the performance of the implemented prototype system and recommend solutions for optimizing the system. Using the provided technical solutions by GTmetrix, we were able to improve the efficiency and optimize the OCCGEOP prototype system. As can be seen in Figure 15, using the GTmetrix tool an analysis was performed through GTmetrix test server located in London using a Chrome browser on 1 November 2020.

Based on the results of this analysis, several solutions were adopted to improve the performance of the prototype system. For instance, using the provided recommendations, the size of the images was optimized in this study. In this sense, by loading optimum size images, we were enabled to reduce the load times of pages. Furthermore, a tile-based representation of map services was adopted as an effective approach. Another recommendation was to avoid using URL redirects. There are many reasons for redirecting the browser from one URL to another, such as indicating the new location of a resource that has moved or monitoring clicks and pages of reference logs. Regardless of the reason for this issue, redirects trigger an extra HTTP request–response loop and add latency for round-trip-time. Hence, the number of redirects provided by the web portal was minimized—particularly for the resources required to start the homepage. The analysis also recommended deferring the parsing of web scripts. Regularly, the browser must parse the contents of all JavaScript tags in order to load each web page, which adds additional time to the page load. Therefore, the initial load time of pages has been decreased by minimizing the amount of script required to render the page and preventing the parsing of the unneeded script until it needs to be performed. Setting a far-future expiration date for cached resources was another suggestion by GTmetrix. The resource expiration date specifies how long a file must be kept in the cache so that in future page views, the file does not have to be downloaded again. Using the far-future expiration strategy helped us to reduce the returning visitor load times. Finally, the removal of references to non-existent resources was another issue that was recommended by GTmetrix and consequently was addressed in this study. By optimization of the OCCGEOP implemented prototype according to the provided recommendations of GTmetrix tool, the two main indicators in measuring the system’s performance, so-called YSlow and PageSpeed, were improved from 74% to 76% and from 61% to 86%, respectively. Furthermore, the pages’ full load times were decreased on average from 3.7 s to 1.8 s. According to the recommendation of the GTmetrix tool, it is expected that the system’s performance will be improved even more by employing other technical methods such as serving static files from a cloud service, avoid unnecessary cookie traffic, and deploying our content across multiple, geographically dispersed servers—the solutions that can be adopted in the complete implementation of OCCGEOP.

6. Discussion

The OCCGEOP integrated the social and participatory characteristics into the conventional attributes of geoportals. The synergy of this integration brings various benefits to an SDI and its stakeholders; several of them will be highlighted here. First, the proposed system builds the capacity for supplying both unused and used user-generated EO products. In this context, the OCCGEOP facilitates the crowdsourcing and sharing of the unavailable EO products and helps to integrate and publish the existing fragmented user-generated EO products on a voluntary basis. Second, the adopted solutions for publishing standard maps from the heterogeneous voluntarily shared EO products in the proposed system realize the interoperability of the shared products and their metadata. These consequently facilitate and accelerate the discoverability, accessibility, and utilizability (use or reuse of shared data [76] for the purpose defined by data consumers) of the shared data and reduce the cost and time of the analyses of these products. Third, the adopted community-based data quality assessment approach (using end-user-contributed scores and feedbacks) alongside the employed top-down approach for screening of the volunteer data producers may help to filter out the poor quality products and reduce the skepticisms in using or reusing such data. Fourth, the existing two-way communication mechanism between data producers and consumers may help to improve the quality of the products and expand the data coverage over time without a centralized management. Fifth, the crowdsourced EO products provided through data as a service (DaaS) [77] strategy to the end-users may benefit the research and applied projects that consume EO data by delivering the EO products on demand for free regardless of geographic locations and affiliations of data consumers. This advantage is more significant in developing countries such as Iran, where the lack of open EO products has always been an important obstacle to the projects. Sixth, the existence of volunteer data providers allows the system administrators and technical personnel to focus on geoportal maintenance and supervision tasks instead of data provision, data manipulation, and publication; thus, this allows for saving time and money. Seventh, the community-based and participatory nature of the proposed model connects the broader community with EO and EO products by increasing public participation and improving the citizens’ engagement in EO, and disseminating open EO products among the public. Last but not least, similar to the citizen science projects, the OCCGEOP may provide learning opportunities for the system users, increase social interactions, and raise awareness of both crowdsourced EO data producers and consumers about the existing various challenges and opportunities on the Earth system spheres.

A comparative study of the main capabilities of OCCGEOP with the three worldwide well-known geoportals, including the INSPIRE, the NASA EOSDIS, and the Global Earth Observation System of Systems (GEOSS) portal, has been performed in this study. INSPIRE is based on the infrastructures for spatial information established and operated by the member states of the European Union. NASA’s EOSDIS has been designed as a vendor to provide key Earth observation data management capabilities from various sources (e.g., satellites, aircraft, field measurements, etc.). The GEOSS portal enables discovery and access to diverse data from independent Earth observation, information, and processing systems [78]. Jiang, van Genderen, Mazzetti, Koo and Chen [2] discussed the capabilities of these geoportals in detail.

Obviously, the functionalities of the implemented prototype and capabilities of OCCGEOP in its current experimental form are still far from the strong design and comprehensive capabilities of the well-established aforementioned geoportals. However, it is possible to compare the essence of OCCGEOP vision and its main capabilities with the vision and main capabilities of the aforementioned three geoportals, especially from the perspective of crowdsourcing.

Table 1. Comparative analysis of OCCGEOP vision and capabilities with the three target geoportals.

Item	INSPIRE Geoportal	GEOSS Geoportal	EOSDIS Geoportal	OCCGEOP Geoportal
Standard Services such as WMS and WCS	√	√	√	√
High Volume Data Coverage	√	√	√	×
Correspondence with Metadata Standard	√	√	√	√
Distributed Server	√	√	√	×
Data Preview	×	√	√	√
Visual Spatial Selection Search	√	√	√	√
Time Filter for Search	×	√	√	√
Providing Crowdsourced Data	×	×	×	√
Downloadable Resource	√	√	√	√
User Identification	×	√	√	√
Online Private Workplace	×	√	√	√
Online Translator	√	×	×	×
Automatic Conversion of User Data to Standard Map Services	×	×	×	√
Online Solution to Receive Feedbacks from Users	×	√	√	√
Interactive User Requests for Publishing Geospatial Web Services	×	×	×	√

presents the comparative analysis of OCCGEOP with INSPIRE, NASA EOSDIS, and the GEOSS Portal according to 15 key items.

In some aspects, such as providing standard map services (e.g., WMS and WCS), correspondence with metadata standards, visual and spatial selection search, and providing downloadable resources, OCCGEOP and the target geoportals all follow the same vision; however, some others are different. The three targeted geoportals adopt a top-down policy driven method to define processes of data entry, transfer, maintenance, and delivery. On the contrary, the OCEGEOP benefits from a bottom-up approach; hence, it is based on the crowdsourced data production paradigm. Although such an interactive communication is primarily designed for the bottom-up processes, it can serve as a coordinator in top-down processes too. Furthermore, compared with the three targeted geoportals, the OCCGEOP can provide unique capabilities such as the automatic conversion of crowdsourced geospatial data to standard map services and user-to-user interactive communication that facilitates the request for the provision of voluntary services. The OCCGEOP is equipped with functionalities that some of the target geoportals do not benefit from. Examples are data preview on the map, time filter for search, create and post metadata, user identification, online private workplace and profile for users, and online solution to receive feedback from users. While the three target geoportals have all been designated to address the big data challenges, OCCGEOP is still weak in this regard and needs to improve the efficiency of high volume and big data coverage. Nevertheless, this is more about using powerful hardware and distributed servers than about the portal’s logical architecture. The three targeted geoportals have the capacity to access distributed servers at a large scale. Eventually, based on this comparative analysis and the 15 items evaluated, OCCGEOP has an acceptable and promising performance. As the present implementation of OCCGEOP is merely a prototype, to make the system more practical, the identified shortcomings can be improved on in future studies.

For further evaluation of the adopted approaches in the system and the capabilities of the proposed model, 40 volunteer experts and practitioners in the area of geoinformatics were asked to use the experimental implementation of the OCCGEOP and assess it by participating in a designated survey conducted in this study.

The participants of the survey were asked three fundamental questions about the visions behind the OCCGEOP (

Table 2. Feedbacks of survey participants on the OCCGEOP vision.

Questions	Answers
Do you agree with the necessity for designing community-based geoportals for crowdsourced EO products?
Do you currently need the Earth observation products that cannot be obtained from the authoritative geoportals?
Do you agree with the ideas used in OCCGEOP being pervasive in the new generation of geoportals?

). The majority of the survey participants (1) agreed on the necessity of designing a new generation of geoportals for crowdsourced EO products, (2) expressed that a geoportal for crowdsourced EO products can supply some of their needs that cannot be addressed in other geoportals, and (3) believed that the visions behind the OCCGEOP will be pervasive in the new generation of geoportals in future.

Table 3. Feedback of survey participants on the main capabilities of the implemented prototype of OCCGEOP.

Criteria	Scores
Spatial Selection and Searching Data
User Friendliness and Clarity of Menus
Data Uploading and Generation of Automatic Standard Map Service
Searching Users and Sending Request Message
Providing Service Details and Map Preview

shows survey participants’ feedback on five main features of the implemented prototype of OCCGEOP. These five main features that were evaluated by the survey participants include the spatial selection and searching of data, user-friendliness clarity of menus, uploading data and automatic standard map service generation, searching users and sending request message, and providing service detail and map preview.

The survey participants evaluated these features qualitatively by rating them using one of four categories: very strong, strong, moderate, and weak. According to the results, on average, 86% of survey participants were satisfied or very satisfied with each of the features and capabilities of the prototype system. These promising results of the survey on the adopted features in the prototype implementation of OCCGEOP showed that the implementation of the robust Django framework and Web 2.0 technologies in OCCGEOP could successfully create user-to-user communication, dynamic, and interactive environments in the geoportal. Generally, VGI is considered as data that are multi-source, unstructured, heterogeneous, uncertain, improperly documented, and loosely coupled with metadata; therefore, interoperability and standardization of VGI have always been considered as challenging issues in the integration of such data in the authoritative data sources and GISs [79,80,81]. In this term, integration of VGI, which is generated in a bottom-up process with the conventional geoportals and SDIs that are designed with the top-down models for the handling of authoritative data, is inherently a challenging issue [79]. However, in this study, the implemented prototype could generally address the aforementioned issues by creating simple web forms, automating conversion and standardization processes, and simple data quality control processes. The OCCGEOP can connect the professionals with amateurs tightly and interactively, direct, facilitate and accelerate the production and sharing of crowdsourced EO products. Moreover, the standard map services in OCCGEOP created through the bottom-up process could be integrated, at least structurally, with other standard maps created by the top-down strategies as well as standard platforms to create robust offline or online and distributed GIS.

7. Conclusions and Future Works

In the new generations of geoportals, taking the advantages of the VGI and developing a community-based environment for facilitating user-to-user communication are considered as two main priorities. In this context, this research introduced a new model for geoportals named “Open Community-Based Crowdsourcing Geoportal for Earth Observation Products” (OCCGEOP) based on the concepts of VGI and community-based geoportals and conducted a prototype implementation for the proposed model for environmental and climate change-related crowdsourced EO products. The proposed model enables user-to-user communication in the geoportal, eases the coordination of the production of crowdsourced EO data, as well as facilitating the administration, standardization and quality assurance, discovery, publishing, accessing, and sharing of the voluntary EO products. The heterogeneity of VGI is one of the main challenges in the integration of VGI in the geoportals. The automated mechanisms for transforming the heterogeneous data structure of crowdsourced EO products in OCCGEOP allow all voluntary maps to be generated in accordance with SDI standards. The conducted comparison of the different features and capabilities of the proposed model with the features and capabilities of three existing well-established geoportals in this study revealed that (1) the proposed OCCGEOP model is compatible with the priorities of the new generations of geoportals and (2) the proposed model has some unique features and capabilities for integration of the crowdsourcing paradigm into the geoportal that the other studied geoportals are missing. Furthermore, our survey about the system users’ beliefs and preferences showed that the majority of the participants agreed with visions of the proposed model and on average, 86% of the participants in the survey are satisfied or very satisfied with each of the features and capabilities of the implemented prototype for the proposed model. The promising performance of the implemented prototype of OCCGEOP made it possible to consider the full implementation of OCCGEOP as a workaround geoportal that enables the handling of increasingly growing crowdsourced EO products.

Given that the selected names or descriptions in the voluntary map services can be expressed in different ways, one of the future directions of this research is to use ontology to resolve or reduce the semantic heterogeneity and contribute to semantic interoperability in OCCGEOP. The OCCGEOP model considered the approaches for assurance of crowdsourced EO data quality. However, in future works, the feasibility of using more robust approaches for the assessment of the credibility and trustworthiness of crowdsourced EO products in OCCGEOP should be investigated. The sharing of events related to crowdsourced data generated within OCCGEOP on social networks is another functionality that can be developed in future studies. In this sense, when a map service is produced in OCCGEOP, a user would be able to share it as an event (including a photo of the map, a general description, and the time of production with a link to the geoportal service details page) on social networks. The idea of sharing EO production events can contribute to the more direct and rapid diffusion of EO-derived information among the general public as well as attracting more viewers and volunteer contributors to the geoportal. In the current research, a survey on the beliefs and preferences of a group of Iranian geoinformatics experts and practitioners was conducted for assessing the quality of the design of the system. In the future, further study will be needed to obtain the opinions of a larger and more diverse group of the local audience, including the users with less experience in geoinformatics. Furthermore, in this study, the prototype of OCCGEOP was implemented in the Persian language to be used in Iran. Therefore, another future direction of this research is to implement the English version of the system to be used by international users. This will make the audience of the developed geoportal more diverse and enable us to conduct a more comprehensive survey on the beliefs and preferences of OCCGEOP users for enhancing the design of the system accordingly. As the OCCGEOP model was developed in accordance with interoperability standards, the various dimensions of integration of the OCCGEOP as a node into a national SDI (NSDI) (e.g., Iranian NSDI) are interesting research lines for future works. Conducting a further investigation on adopting the distributed servers to handle high volume and big crowdsourced EO data at a large-scale is necessary and is a high priority for the development of OCCGEOP. Another direction is to use the OGC APIs in developing OCCGEOP. In this sense, by using the resource-centric API solution presented by OGC APIs, reaching more modern, effective, and rapid web development would be possible. While OGC services usually use the Representational State Transfer (REST) protocol for communication, using OGC API in developing OCCGEOP can enable us to use any style of communication and improve interoperability in the (Information Technology) IT industry. Similar to the major existing SDI geoportals developed for EO products, OCCGEOP mainly focused on publishing, finding, and accessing EO products. However, future research could examine the feasibility of integrating geoprocessing services in a standardized way through OGC’s Web Processing Service (WPS) as a marginal service for the system. In OCCGEOP, data are provided and evaluated by users for the users. Therefore, the ultimate success of OCCGEOP is tied to the participation and engagement of the citizens in the system. In this sense, alongside the technical and technological aspects of OCCGEOP, future research should be conducted to determine the effective approaches for attracting citizens and sustaining their engagement in the system.