Updating geo-information in a heterogeneous networked environment – Experiences and evaluation of OpenGIS Web Feature Services

A Basic WFS implements the GetCapabilities, DescribeFeatureType and GetFeature requests. A client can request for an XML encoded capabilities document (indicating which feature types and what operations are supported) by sending the GetCapabilities request to a web feature server. The function of the DescribeFeatureType request is to generate an XML-schema (2004) description of the feature types serviced by a WFS implementation. The GetFeature request allows for the retrieval (of feature instances and selected set of their attributes) and uses filters from the OpenGIS Filter Encoding (OGC, 2001) to constrain the data to retrieve; see Figure 1.

http://www.someserver.com/servlet/wfs
?request=GetFeature
&FEATUREID=TEST_BOUNDARY.1000
Figure 1 Request to retrieve the TEST_BOUNDARY with FeatureId 1000 (KVP request using HTTP GET)

A Transactional WFS offers functionality to modify geographic features as well; that is insert, update, and delete geographic features (see Figure 2 for an insert). In order to do so, a Transactional WFS implements the Transaction request (a set of insert, delete, and update actions that belong together). It could optionally implement the LockFeature and the GetFeatureWithLock request. When the transaction has been completed, a Web Feature Service will generate an XML response document indicating the completion status of the transaction (and a list of newly generated feature identifiers assigned to the new feature instances). The purpose of the LockFeature request is to expose a long-term feature locking mechanism to ensure consistency and avoid editing by other users at the same time. A Lock element uses a filter to specify what feature instances should be locked. Finally, by using GetFeatureWithLock instead of the GetFeature request, a client requests for features to be retrieved and locked at the same time.


Figure 2 Fragment of the Transaction-request for a new draft_boundary.

WFS requests and responses are sent between client and server using the Hypertext Transfer Protocol (HTTP). There are two methods of encoding WFS requests. The first uses XML as the encoding language, the second uses keyword-value pairs to encode the various parameters of a request. An example of a keyword value pair (KVP) was already given in Figure 1. The same request but now as an XML encoding is given in Figure 3. In general KVP requests are shorter, but using KVP for transaction requests is limited. KVP-requests are sent using HTTP GET, while XML-requests have to be sent with HTTP POST. In both cases (XML and KVP), the response to a request or the exception report must be identical.


Figure 3 Same request as in figure 1, but now as XML encoded request ( using HTTP POST)

3. Case study: notary drafts parcel
As an example of cadastral transactions, one could think of a notary who sketches a new boundary because a parcel has to be divided into two new parcels as the result of a property transaction. Instead of drawing the new boundary on a paper map and sending it by postal mail to the cadastre, it would be more efficient when the notary could sketch the new boundary on a digital map in a Web client and send the digital boundaries to the cadastral database via a Web service. These draft boundaries are stored in the cadastral database as preliminary boundaries, and can be used as input when the exact boundaries are surveyed by the cadastral surveyor.


Figure 4 Web Feature Service for notaries to draft new parcels and boundaries in cadastral database, optionally using topographic data as background.


Figure 5 The server consisting of Oracle (DBMS), GeoServer (WFS) and Tomcat (webserver, Java platform)

In the Web client the data from the Dutch cadastral geo-database LKI serves as background for drafting new boundaries and parcels. With a spatial query (based on the current bounding box) also other data, like orthophotos or topographic data from other WFS or WMS services, can be added in the client as additional background information. The WFS service should make it possible for notaries to access the LKI database over the cadastral network (Internet), as illustrated in figure 4. Since the notaries do not need advanced GIS tools for complex analyses of data, a simple front-end for viewing and editing geodata would be sufficient. The client should consist of a viewer/editor and some layer that “talks” WFS, i.e. transforms operations from the viewer/editor to valid WFS requests and handles communication of requests and responses with the web feature server. The server has a data layer (consisting of an Oracle database with cadastral data), which is accessed by the WFS layer and “responds” according to the WFS protocol.

The open source WFS server GeoServer (http://geoserver.sourceforge.net) has been used in the case study. GeoServer is a full implementation of the WFS specification of the OpenGIS Consortium. GeoServer can be configured as a Transactional web feature server on several data formats, including Oracle Spatial (the cadastral data used in this case study is stored in an Oracle database). We used GeoServer in combination with Tomcat as webserver and (Java) servlet engine, as in Figure 5. Because existing (open source/ freeware) WFS clients are either not fully compliant with the specification or not Transactional, a prototype client oriented at developers needed to be developed. The developed client uses SVG (2004) for visualization. SVG can be generated by transforming the GML output stream with an XSLT (2004) stylesheet (see Figure 6). More information can be found in (Brentjes, 2004).


Figure 6 From SVG to GML/WFS. The white box below – in the blue frame - contains a part of the WFS-request to add to the Transaction request.

4. WFS interoperability
A basic principle for interoperable services, in this case WFS, is that any WFS client should be able to communicate with any WFS service. This means that both client and server have to comply with the OpenGIS WFS specification. For interoperability of the server it is important that the web feature server can provide valid GML. Validating the GML from GeoServer against its schemas showed that the produced GML is valid. All kinds of WFS compliant transaction requests have been constructed with the developed client. Transactions consisting of insert, update and delete operations, in random order and different quantities have been sent to the server. These transactions were all processed successfully.

Besides the case study client, other WFS clients have been tested. GeoMedia Viewer does not accept restrictions (see Figure 7) that are defined in the XML-schemas of feature types. If these parts of the schema are removed, then GeoMedia Viewer accepts the features, although there still is a problem with handling the Dutch spatial reference system (EPSG:28992). The fact that features from an 'unknown' data source can be retrieved, visualized and queried by just any WFS compliant Web client shows the power of interoperable Web Feature Services. Unfortunately, no other Transactional clients than the developed client could be tested, simply because no open source or freeware Transactional WFS clients were available.


Figure 7 Example of a part of an XML-schema. Restrictions are defined by the -element


Figure 8 Two (independent) Web Feature Services accessed by one WFS client



Page 2 of 3
Previous | Next