The design of Geo-Wiki follows the guidelines for the development of a standards-based geospatial portal as outlined by the Open Geospatial Consortium (OGC, 2004). This Geospatial Portal Reference Architecture is based upon the principles of Service Oriented Architecture (SOA), where services are discoverable on a network, facilitating data integration and interoperability (Erl, 2005).
The Geospatial Portal Reference Architecture outlines four classes of service that are required in order to be OGC compliant: portal, portrayal, data and catalog services. Geo-wiki contains a portal service for system management and as a single entry point to the system. The portrayal service is implemented as a Web Map Service (WMS), which is used to display the geospatial data as images on Google Earth. The data service consists of a Web Feature Service (WFS) for serving vector data and a Web Coverage Service (WCS) for serving raster data. Although implemented, these services are yet to be fully integrated into Geo-Wiki. The WFS will be used to serve the crowd-sourced data in vector format while the WCS will serve the hybrid map and disagreement maps in geo-tiff or another raster format. The Catalog Web Service (CWS) is a metadata portal which serves the metadata of all the products in Geo-Wiki and conforms to ISO 19115 standards. The GeoNetwork metadata portal is directly accessible from Geo-Wiki or directly here.
Figure 1 provides a schematic of the general Geo-Wiki architecture, which consists of different standard components integrated into a single portal. The map layers and data products are contained in two separate repositories shown at the bottom of Figure 1 (click here for more information on data sets). The first repository contains the global land cover, disagreement and hybrid maps. These datasets are displayed using a WMS that uses the open source MapServer data rendering engine. This software was originally developed by the University of Minnesota and is a now a project within the Open Source Geospatial Foundation (OSGeo). The second repository contains a database of the Geo-Wiki users, their land cover contributions, and the pixel polygons with attribute data from the three global land cover maps. This database is accessed by the web portal to authenticate users, access the pixel polygons and store the contributions from the users. More information on the database design is provided below.
The reasons for choosing Google Earth were the 3D visualization capabilities and access to high resolution imagery via the Google Earth API, which were not available at the time in 2D Google Maps. The advantage is that a stand-alone 3D-application does not require installation on the client computer but a simple web browser can be used to access the application. However, the appropriate plug-in for Google Earth must be installed, which is a potential barrier to those individuals who simply want to view the application quickly. Other advantages of the 3D visualization include the ability to use the height perception to differentiate between land cover types, e.g. shrubs and trees, and the fact that the presence of high resolution imagery can be seen immediately on Google Earth. In Google Maps, the user must zoom in before the high resolution images appear. However, now that high resolution imagery is available in Google Maps, a 2D application may be developed in the future using Openlayers.
The database behind Geo-Wiki is the open source PostgreSQL relational database with a PostGIS extension to allow for spatial queries. The database stores the user details, user validations and the pixel polygons of the three global land cover data sets. Although the global land cover maps can be viewed as a semi-transparent layer on Google Earth, the bounding coordinates of each pixel are stored in the database. This representation was chosen in order to quickly retrieve the outlines of the pixels and their attributes at any given point on the Earth’s land surface. This is illustrated in more detail in the section about Assessing land cover. The pixel polygons are stored as binary PostGIS geometry types with a spatial reference system (SRID) of 4326 (WGS84/latlon). The PostGIS language extension allows for the very easy and efficient export of data into different formats by supporting queries such as ‘select AsGML (the_geom) from tbl_polygon where id=1000’. To retrieve a specific polygon from a spatial query requires a database index on the geometry. The commonly accepted GiST index has been used for this purpose and has proven to be very fast, even on a table holding nearly two billion polygons. The user contributions are stored in a separate table either as POINT or POLYGON geometry depending on whether the contributor has provided information on a single pixel or a whole area. For a single pixel, the POINT holds the coordinates of where the user clicked on Google Earth rather than the land cover pixels as this is a much more efficient way to store the data. When required, the point data can be matched to the pixels of the three land cover data sets using a simple query function. The id of the user is also stored so a ranking table can be created to display the top contributors, and to allow users to download their own contributions for their specific purposes.
Last edited: 22 August 2012
Program Director and Principal Research Scholar Strategic Initiatives Program
Principal Research Scholar Novel Data Ecosystems for Sustainability Research Group - Advancing Systems Analysis Program
Return to Geo-Wiki main page for
International Institute for Applied Systems Analysis (IIASA)
Schlossplatz 1, A-2361 Laxenburg, Austria
Phone: (+43 2236) 807 0 Fax:(+43 2236) 71 313