Versioning Vespucci

OpenGeo’s mission to bring participation and openness to the geospatial domain extends beyond software to geospatial data itself. We have been working on tools for collaborative mapping in our mission-driven time for years. Western Australia’s Landgate agency shares this enthusiasm for crowdsourced data managing. It recently took leadership in the area by funding a proof of concept using a collaborative mapping user interface with a versioned geospatial back-end.

Our live demo is an augmentation of an application we originally built for Livable Streets. Chris Tweedie of LandGate adapted it for their purposes.

The Versioning Stack

The application uses the full OpenGeo stack. Data is stored in PostGIS and served using version-enabled GeoServer. The base map tiles are cached using GeoWebCache. The client-side JavaScript code is from the Vespucci project, built using OpenLayers.

WFSV is an extension to the WFS standard for requesting geographical features over the web that supports versioning requests, like requesting a feature at a specific revision or a log of changes to the data. OpenGeo has developed these extensions in-house, but we hope for them to one day be accepted as an OGC standard. A version-enabled GeoServer supports WFSV; client side support for WFSV requests is available in the WFSV sandbox of OpenLayers.

Below is a quick walkthrough of the features of the demo.

The Guided Tour

You can access most of the versioning functionality through a feature’s popup. Try clicking on any of the features on the map to open its popup, and notice the History link.

In the versioning demo, a feature's popup now has a History link.

History. Clicking on the History link shows you the feature’s history–the revisions at which the feature was created and edited–in the sidebar.

This is the view of a feature's history that Vespucci makes available.

The client requests the information for the history log from GeoServer using a WFSV GetLog request. Each revision in the response comes with its “commit message”, date, author, and other useful information.

In addition to viewing the full list of revisions, you can select two revisions and see the differences between the two by clicking the Compare Versions link.

The feature's Diff view shows how a feature's attributes and location has changed between two revisions.

Differences. The “compare versions” view shows the differences in a feature’s attributes and geometry across two revisions. Changes in attributes appear in the table at the top, changes in geometry in the thumbnail maps below.

The information used in displaying the differences comes from two requests. One is a WFSV GetVersionedFeature request that gets the state of the feature at the first revision. The second is a WFSV GetDiff request, whose response is the WFS-T transaction (Update) that would transform the feature from the first revision to the feature from the second revision.

The thumbnail maps are each bona fide OpenLayers maps, with their own WMS background layers (drawing from the same GeoWebCache as the master map) and with Vector layers that display two OpenLayers features–one corresponding to each revision.

When the differences to the feature are rolled back, it returns to an earlier version's location and attributes.

Rollback. When a the Roll back these changes link is clicked from the Diff view, the client issues a WFSV request to the server that triggers the rollback.

Next steps

We built this application as a proof of concept for Landgate. But there is much more work to be done, which we will take on when we find the funding or spare hours for it.

We think that version-support in map applications is critical to collaborative mapping, just as versioning is critical for environments like Wikipedia. Non-traditional ways of building maps will require non-traditional tools, and the ability for crowds of people to review data, both through inspecting the present state of the data, and reviewing its history.

We are eager to polish the design of our collaborative mapping UI’s. One way we will be pursuing this is to take lessons learned here and bring them to our new web mapping UI project, GeoExt. Ideally, we would like to see the UI components from this application available as GeoExt components that can be used to quickly build new applications.

Last but not least, we are always looking for opportunities to improve out backend versioning support. With Paul Ramsey on our team, we have the potential to build versioning natively into PostGIS/PostgreSQL (whereas it is currently managed by GeoServer itself). We would love to be able to expose the advanced versioning features of other spatial databases–like Oraclae 11g Workspace Manager and ArcSDE’s versioning–to any user on the web through WFSV.


One thought on “Versioning Vespucci

Comments are closed.