I’ve begun technical advising on the next iteration of a collaborative mapping project, to collect, discuss and disseminate data and stories on deforestation in Democratic Republic of Congo. I first began thinking about it over a year ago, with this write up on Moabi and GeoWeb challenges, and have since helped WWF iterate on the old platform with Sigaptaru. Right now, I’m at the offices of IIASA, a global scientific research institute situated outside Vienna, in a castle. A few weeks from now, I’ll be in Kinshasa, challenging most all of my assumptions about the project.

Right now, I want to challenge some of the technical direction this project is taking, and I hope you can help. I may be in danger of seeing every map through an OpenStreetMap lens; though it’s possible I may be on to something.

Naturally, I want this project to be based on existing, active open source projects. Architecturally, we favor focused components integrated through appropriate data sharing and APIs, over a monolithic system. In Moabi, this means good functional separation between data management, and exploration presentation and communication, with links back to dig in if desired. We’ve starting talking about this as the difference between the kitchen and dining room (though our kitchen would be open plan, and anyone can come in and cook. The analogies are endless). There are groups of folks already collaborating on creating and sharing DRC data, but “bilaterally” and without a full community or tool for coordination. The data collected in Moabi is relatively specialized, like details of mineral right concessions, REDD+ project boundaries, field surveys, artisanal logging sites, proposed road projects, etc.

So the model of collaboration and collection of geographic data does have some parallels to OpenStreetMap (if a smaller potential contributor base), but the data itself does not always fit into what’s appropriate for OpenStreetMap. Does it then make sense to fork the OSM rails port, and build off the same code base?? And further, model the community interaction and experience of working within this amazing project for the past 8 years? OSM is certainly the most successful mapping collaboration out there. MediaWiki, the software behind Wikipedia, is reused a tremendous amount. Perhaps there’s a similar dynamic possible. The USGS took this approach when looking to work on the National Map. And it’s not just the rails app, but the leverage of the entire architecture of planet dumps, map tiles and indexing, the great new iD editor, a well developed import process, flexible consensus based discussions of representations in tags. As the OSM app and associated tools get better, a system based off it can improve in parallel. The National Park Service has been working on beautiful and usable ways to distribute their maps as Park Tiles, and we could model that as well.

The question is, what’s missing in OSM that’s part of the Moabi requirements, how hard would it be to build these new features, how difficult will it be to maintain a branch, and how much of these features are useful to OSM core?

Here’s some of the departures from current OSM that we’ve discussed. There needs to be some internal definition of a feature layer, and we may need permissions or at least focus on particular tags on particular features for particular user groups (ie some fields may be imported but need not be edited in Moabi). Perhaps the way iD is representing forms for objects could be useful here. Imports need to be properly marked and sourced; this might mean flagging user accounts as import or bot accounts. Collaborators need a space to discuss the focus of data campaigns, which could be a geographic region and/or a topic, a way to set a number of data goals and monitor progress of those goals. Some of those goals could mean a kind of quality control.This could be an implementation of Groups, as we started during the SOTMUS code sprint, integrated with an enhanced Tasking Server. A group might have a leader. Feature layers are published as tile sets, which are composited together by the tile server in different ways. A kind of CMS could power the front end, displaying various maps, highlighting useful work, telling stories behind the data, sharing out.

What’s the alternative to building off OSM. Well, I guess that would be GeoDjango. Not a bad start, and flexible.

Would love to hear thoughts from those of you who experienced with building web mapping applications, developers of the OSM website, and anyone else who thinks this is a great idea or the first step towards painting ourselves into an OSM shaped corner.