A handful of months ago I met Kersten Jauer, UN Information Officer for the Central African Republic (CAR). CAR is a large country in Central Africa, surrounded by Sudan, Chad, Cameroon, Congo, and DRC; 67% of its population lives with under $1 a d
ay and is scoured by constant internal rebellions and gender-based violence.
Kersten spends a lot of the time in the field in CAR, and put together an amazing map of the whole country to support logistics and NGO programs. Roads, provinces, bridges, fuel pumps, it all got captured by hand in Google Earth and saved as KML files. By the time I got it, Kersten’s KML had grown to be 11 MB, an amazing amount of information patiently collected and edited, and periodically shared online with all those working to improve the region.
Contrast the map above showing the CAR KML with the map on the right showing the same region as seen by default in Google Earth. What got my attention was a little note in the KML:
If you would like to comment on this file or have suggestions please email to MapsAndGoogleEarth+car@hcpt.jot.com
To add a placemark just email it with a short description to the same address or kersten.jauer@undp.org
Please also check out the maps section on http://hcpt.jot.com
The map was built collaboratively, but imagine the workload Kersten must have had getting little snips, integrating them on the larger map, and then letting folks know of updates. And how would the map be maintained whenever Kersten was attending to some emergency?
Mesh4x KML Adapter
We started building a simple instance of a KML adapter for Mesh4x this week. This adapter would allow a team of people edit a KML file and then ‘synchronize’ it with all the others. For example, I could add a pushpin saying a bridge is down, and you could be editing another pushpin or moving it around to represent that a logistics truck has moved. When we synchronize, the truck moves around in my KML and the broken bridge appears in yours.
This could be synchronized peer-to-peer (a KML on your disk to a KML on a USB drive or someone else’s box) as well as via a ‘cloud’ web service. Note this is changing the data inside the KML, it is not just ‘file sharing’. The adapter knows about KML and keeps track of versions of fine-grained elements (pushpins, placemarks, polygons) inside the same file. It is an example of how a data mesh could be used to synchronize fine-grained data between applications.
We chose KML for this adapter as it is a standard (“OGC KML”) that is widely used and supported by Google Earth (of course), Microsoft Virtual Earth, as well as nice tools that work offline and can be used in the field such as GeoPDF.
We have a sample UI (shown here) to let you play around with the basics. The effort is still on the libraries and we don’t have a neat UI to let you choose endpoints or resolve conflicts, but all will come in due time. Other restrictions include having to put your placemarks in a “Shared Items” folder in your KML, and styles don’t get replicated. We foresee no problems working out these constraints over the coming weeks.
To try it out, make sure you have Java installed and:
- Get the sample application from http://code.google.com/p/mesh4x/downloads/list
- Double click on mesh4j-KML-DemoApp.jar
- Point to a KML or open the sample ones
- Edit the location of Sample Pushpin 1 in File 1
- Add a new pushpin in File 2
- Press synchronize, and after both files should have the updated Sample pushpin 1 AND the new pushpin!
Another advantage of a data mesh is that endpoints can be heterogeneous, as long as you do the appropriate mapping. Eventually you will be able to sync a spreadsheet with columns such as Title/Description/Lat/Long into KML pushpins and back quite easily.
We hope to be showing this at Where 2.0. A lot of the team has been focusing on supporting the Myanmar disaster relief, so progress this week has been a bit random, but we still want your feedback!
Learn more about Kersten’s Work in CAR at www.hdptcar.net, or get Kersten’s latest epic KML.
See the Mesh4x project at http://mesh4x.org