So after a lengthy hiatus, it’s time for me to get back in to the whole collaborative mapping thing. I’ve been thinking about such things a lot lately, and didn’t have time to get to most of it at my Where 2.0 presentation. We’ve also been making progress in GeoServer to support all kinds of collaborative mapping – put the power in the hands of users to determine their workflows and permissioning. I’ll roughly break things up as I did in my talk – the premise is that the grass roots remapping can’t be stopped, but that there may be ways to help it go faster. We’ve got Open Street Map, obviously the clear leader with an amazing community. But while something like a collaborative street map may have wikipedia type properties – where it makes sense to have a single community crystallize around one – there are many, many more maps to be made than just road maps. And while there are lots of software packages that aren’t MediaWiki (what runs Wikipedia), there are practically no options for collaborative mapping. So The Open Planning Project (TOPP), my employer, has been putting a lot of effort in to making GeoServer a better platform for collaborative mapping. We’re looking to make it a flexible platform for different communities to experiment with a variety of workflows, figuring out what works for them. The 1.6.0-beta1 release should show off some of what we’ve been working on.
The low hanging fruit seems to be simple reporting functionality. I’ve been talking to several different non-profit groups, and many just want an interface for users to throw some information on the map – a point and a description, like Google Earth. But they don’t want to be passing KML files all around. Which speaks to one way I’ve been articulating where we’re going with GeoServer – ‘cvs for the geospatial web’. We give you a central location where you can do insert, update and delete on your data. And our latest improvements are to do the versioning – history, diff, rollback – so you can keep editing the geospatial information and not be worried about non-experts corrupting it since you can always revert changes. We’re building this on top of the WFS-T standard, and let normal WFS-T clients use versioning transparently – that is their edits will go through fine, and will get versioned with out them even knowing. Version aware clients will be able to take advantage of the additional functionality – getting a log and a diff, doing a rollback, ect. Ideally we have a variety of clients – web based, mobile based, desktop, ect. Past the basics we’re thinking about a lot of workflow customization.
So the next few posts will explore in more depth some of the economic aspects, some ideas on the technical side – what further tools and functionality would be helpful, and the legal ground we need to clear before collaborative mapping can really take off.