Moabi and Big Important Challenges for the GeoWeb

Recently finished a technical review of WWF’s Moabi platform, their geodata sharing platform to track deforestation, and came out with some important technical challenges for the GeoWeb I want to share with the mapping nerds.

Just following TAI’s bridging session on natural resource governance, I met Charles Huang of the World Wildlife Fund at a similarly styled event at the World Bank. After self-identifying as a developer, Charles asked if I’d like to talk more about Moabi … they needed a developer’s eye on the platform as they considered how to move to their 2.0. This isn’t GroundTruth’s usual sort of work, but considering the TAI Bridge effort to connect technologists with sector experts, our other work with Drupal and mapping, and my own deep interest in conservation, I dove in.

Moabi is ambitious. In its current expression with DRC and deforestation, the platform is meant to collect geographic data and detailed profiles from all sorts of courses, including the “crowd”, on everything from mining concessions, informal logging, road construction, to REDD projects, and enable conversation and coordination among everyone conservation workers on the ground, government officials, and the interested public on the other side of the world. And in the long run, this platform is intended to apply to other places and focus areas of WWF. This is such an ambitious, wide mandate, and I think touches on 3 key technical developments for the GeoWeb.

Features as Full Social Objects

In Moabi, every single feature, such as an individual mine or road, has a profile page, which should be shareable, pivotable, a focus point for social interaction among people and groups organizing to prevent deforestation. Most often in GIS and web mapping, we talk about layers of information, and while individual features often have expression in various forms on a site, there is no open source software package that deals with feature-level data in this way out of the box. And there’s not really that many examples to draw on. Every feature in OpenStreetMap has an individual url, with details on its tags, last editor, etc. But it’s not quite used as a social object, excepting maybe the awesome machine tag integration with flickr. Foursquare has some elements of this, every venue primarily being a place, and users able to connect to that place. But besides these sorta examples, a geographic feature is generally treated as a property of social objects, rather than social objects in themselves.

Multi-master sync and flexible schemas

Data is Moabi is sourced from both government, civil society, and interactions on the site. Those source databases are very likely to update over time, and very possibly they will receive updates on Moabi as well. Given a foreign key, or even a clever lookup, at least identifying which features have updated is possible. But this inevitably leads to thorny issues of handling conflicts during synchronization. This is commonly experienced in the simple situation of editing in OSM during a mapping party, where two editors independently modify the same feature. The OSM API can detect the potential conflict, but once detected the interface and process to resolve the conflict in JOSM is not intuitive or easy at all. When writing code, this situation happens all the time, and simply being text, it’s simple enough to throw the problem to the programmer to resolve. But we’re talking about geographic features here, and that’s going to take very well designed interfaces to solve properly.

A related issue is that a single feature may contain pieces of information from several different masters. Take roads. Yes, common enough is the geometry, maybe the name (or names) of the road, the surface. But with Moabi, they may also want to know if the road has a regular anti-poaching patrol, or if it’s commonly used to transport lumber. OSM deals with this unpredictability of attributes through tags, arbitrary key-value pairs, with no predetermined mandated structure, with conventions of use worked out over time. In contrast, traditional GIS requires pre-decided database schema, leading to long running discussions which often never resolve to the point of actually collecting and sharing data. So why not just use OSM? Well I’m not sure it’s best to keep every single thing interesting to Moabi about roads in OSM, and some features, like say mining concessions or REDD projects, may simply not be appropriate for OSM (this is up for discussion of course). So assuming that something else is needed, what are the options for a tagging based system that’s not OSM? The closest I’ve seen is Matt Berg’s work at Earth Institute on georegistery, an open source db with RESTful API for sharing and versioning geographic objects in GeoJSON, with arbitrary attributes.

Complex interactive experiences without a lot of fuss

Moabi has a lot of data, two dozen layers, thousands of features. Currently the only way to work through the data is via query, which can be a little slow both in usability and response time. Interactive exploration is best accomplished through Tiles and Grids, as enabled so well in TileMill and MapBox. And there’s been a lot of activity in OpenLayers with Grids, including support for interaction in multiple layers.

The issue comes with how to make this architecture efficiently queryable. Say you wanted to show only to show mines operated by Chinese companies in the DRC, which are not located in mining concessions. The most obvious way is to send this query to the server, and render the result on the client side. But perhaps there are other ways, utilising the same approach MapBox Streets takes to customize styles on the fly, by manipulating the color table of tile images. If a tile set handled just a single layer, then the color table could someohow be used to encode other properties. This would essentially pre-can a set of interesting queries during tile generation, with the query results rendered by the server. If that’s too limiting, perhaps we need to start thinking further in the future, where something like SVG based tiles could be efficiently rendered and queried in the browser.

Thoughts?

Would love to hear feedback on whether these are actually interesting challenges in your opinion, and what are some other ways of moving forward with them.

4 Comments

  1. John Waugh said,

    April 24, 2012 @ 1:40 pm

    Mikel, thanks for the review of Moabi. This is ambitious and could become a really important tool as it evolves. A lot of data is missing from the existing categories, which is not surprising given how new it is. What is more surprising is the relatively limited scope of the exercise so far. Given WRI’s involvement, I would have hoped to see some sort of link to poverty mapping for example – but perhaps the data is not there to support that. But what about conflict mapping? Could this be cross linked to an existing conflict map or could conflicts be added as a category for user input? Basic social and governance information is still missing, like the boundaries of the groupements, ethno-linguistic domains, population, etc. These are decidedly not beside the point for conservation planning in the DRC. Anyway, its early days, and the features used probably reflect an availability bias.

    Much will depend also on how easy it is to add information. Will it be possible for field biologists to upload observations? Will it be possible to input and/or access data using apps on handheld devices?

    It will be very interesting to consider how to weigh the relative value of contributed information. Will there be a reputation assigned to contributors based upon past contributions (like is seen at some help-desk sites)? Or a star or usefulness rating like Amazon’s product ratings and reviewer ratings? So that, when you ask for example for data on informal logging, you can ask that field observations be included, but only from observers with a “3″ or above ranking? That sort of thing.

  2. Sean Gillies said,

    April 24, 2012 @ 4:11 pm

    I’m still very interested in making geographic features addressable and distributed. Putting everything in one database, whether Moabi or OSM or Geonames or Pleiades, has its limits, so we’ll need to figure out not only how to synchronize, but how to meaningfully reconcile our common features. And if we want to consider long spans of time, we’ll also need to figure out how to treat succession of features. For example: the Nereid Monument (http://en.wikipedia.org/wiki/Nereid_Monument) was once in Asia Minor, but is now in London. Same object, different location? Having fallen into ruin and since reconstructed, is it a different object?

    “Cool URIs” seem to me to be a requirement for geographic features that would be social objects and things to be tagged or annotated on the web. Does Moabi have these? Is it taking a different approach?

  3. mikel said,

    April 24, 2012 @ 4:46 pm

    John, good points. There’s a lot of data already there, but definitely so much more to bring in as well .. much of it not readily available, due to data sharing policies, or simply not existing with much precision. There is a lot of work to do on usability, and different user approaches. As you say, the mobile field worker is going to need an entirely different approach. Reputation is important, there are currently ratings on features themselves, which I think is actually social overkill; ratings or reputation on contributors is a bit more useful.

  4. mikel said,

    April 24, 2012 @ 4:48 pm

    Moabi currently has individual features identifiable by a unique and relatively cool URI, but they are behind a registration wall which prevents sharing. I’ve recommended that change, but there are some issues to work through with the various sources of data.

RSS feed for comments on this post · TrackBack URI

Comments (4)