GeoCollaborator

Introduction

GeoCollaborator is conceived as a tool to enable collaboration on GeoSpatial data. The root of this idea is taking WFS-T, the specification that lets one do Insert, Update and Delete on features - in other words, to modify the map - and make it more accessible and useful.

Inspirations

The main inspiration of GeoCollaborator is to enable Architectures of Participation around GeoSpatial data. GeoCollaborator hopes to tackle the technical component of the Architecture, while allowing for innovation on the social component. The technical improvements are akin to CVS and asynchronous version control systems and 'patches' in software, which provided the technical underpinnings for diverse contributors to build software together. The equivalent is lacking in Geographic information, as the systems that can version and allow users to edit geographic data cost thousands of dollars. They also require lots of training, instead of just being well designed for diverse users. For the social aspects, we hope that an easy to use and highly configurable system will enable communities to innovate and find the governance patterns that work best for geographic information. Just as there are different ways of running Open Source Software projeccts, so too do we believe that different sets of shared geographic information will have different levels of committer rights and policies to prevent vandalism and to maintain high quality information.

The Public Participation GIS movement also provides inspiration, but we believe one of the main reason it's never caught on is because there is no open source software to enable it. And what can enable it is poorly designed, aimed at specialists instead of contributions from 'amateurs'. Open Street Map points the way forward, as diverse contributors collaborate on data for a street base map, using GPS and an online editor.

Next Steps

There are two next steps to make geoserver a better platform of geospatial collaboration. We already have the basics, with WFS-T's Insert, Update and Delete operations, which can be performed with uDig, MapBuilder, or MapBender. The next step is to improve the existing infrastructure to get 'wiki' capabilities for maps. For us the two defining features of a wiki are the attribution and the ability to 'diff' and 'roll back'. For the first we need to put a bit more of a security framework in place, for the second we need [diff and rollback in WFS-T]. If you have ideas on how to implement these, please contribute to the discussion pages (from the links in the previous sentence). These two features will get us to the requirements for Open Street Map, the features they always point to as lacking in WFS-T. For the most part they should not be part of the WFS specification, except for maybe a rollback operation. The rest can be accomplished with profiles and security additions on top of the base spec.

Further Steps

After the basics, things get much more exciting. Instead of a static two part collaboration infrastructure - attribution and diff/rollback - we are looking to build a flexible framework for GeoServer administrators to define their own process. So the transaction operation will be set up for plug-ins that can perform operations. Past the first two plug-ins (authentication and version history), the obvious next one is the [validation engine]. This was developed by Refractions, and it can take the onus off of human peer review and automatically reject attempted entries that aren't up to snuff. The admin can define rules like 'no geometries that intersect' or 'no roads that don't have names', to prevent a lot of common vandalisms.

Another plug-in that would be relatively easy to hit is notification. Many wiki's have this functionality, sending emails when a certain page is modified. The same could be done with an area of the map. Past that we could output GeoRSS. Ian Turton has had some success with this. Another possible plug-in could be a 'peer review' holding area, where some one must explicitly approve a change instead of checking after and rolling it back. It'd also be nice if there were an easy way to make a geospatial 'patch', just like software does, that someone could review and then 'check-in'. There are more plug-ins that can be imagined, but the result of all this should be that GeoServer with GeoCollaborator could slot in to an existing organization's workflow, that they wouldn't have to change it to the software, but the software would change to them. This also opens up new spaces of collaboration, such as citizens suggesting improvements that flow back in to the government's base maps. Organizations could also just use it internally, and people could use it entirely externally, to collaborate on new layers.

The future

What we hope to see happen with this is innovation with how the tools are configured and how the social community is set up. We believe that the open source 'process' can be applied to geographic information. Right now it's just the Open Street Map crowd on the cutting edge, people making maps in their spare time. But we hope to provide the tools that will enable bigger collaborations, eventually to have it make more sense for large companies to invest in a common basemap under an open access license instead of paying the large data providers.

Why not Open Street Map?

Some may ask why we don't just implement this functionality in Open Street Map, since they already have the basics and a great community. The root of the reason we're not just working directly with them is that we want to enable any group to collaborate on geographic information, not just on street maps, and we want to make a system that lets administrators choose how to set up their community of collaboration, not have implicit assumptions about the social architecture written in to the technical architecture (which OSM does about a wiki approach). Further more, we feel a strong focus on open standards is essential, to allow software designed for different systems to interoperate with ours. By leveraging WFS-T, we already get uDig, MapBuilder and a number of proprietary applications as well, that need only slight modifications (or sometimes none at all) to take advantage of the enhanced collaboration plugins. Also by leveraging GeoServer a variety of spatial databases can be used as the backend, and the content made by groups of contributors can also be delivered with industry standards protocols (WFS and WMS) and formats (jpeg, png, svg, kml, pdf, ect.). We hope that eventually our software will get good enough and flexible enough that it could actually power open street map, combine with their effort and bring a standards-compliant view on to their DIY API's.

Added by Chris Holmes, last edited by Chris Holmes on May 16, 2006  (view change)

Comments

Ian Turton says:

Excellent idea Chris. I've been coming towards this from a different direction (see my blog here and  here). We've got a system that handles the monitoring what people are looking at as well as the reading/writing to the wfs/t. The next stage is to start sending out the WFS/T transactions as GeoRSS updates. Since I have the code for bbox watching already talking GeoRSS the next stage shouldn't be too hard. And as I'm suposed to talk about this for 30 minutes at GeoWeb2006 I guess I'll need to make it work soon.

View Attachments (0) Info