Archive for April, 2012

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.


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.

Comments (4)