OpenStreetMap
The American Red Cross GIS Team is constantly looking for new ways to improve our workflows and learn from the OpenStreetMap and FOSS4G communities. I’m proud to say that 95% of the GIS analysis and map making we do is done using FOSS4G tools.
A couple of years ago we realized that to be effective consumers of OSM data and FOSS4G software we would need to start contributing and developing ourselves.
In the aftermath of Typhoon Haiyan we identified a need for a better OSM field data collection tool that could work with structured surveys. Eventually we created OpenMapKit with initial seed money from USAID Global Development Lab. We have used OpenMapKit in several Missing Maps field mapping missions last year in Zimbabwe, Rwanda, Tanzania, and Bangladesh. During these field trials we noticed that we were continually in need of an OMK compatible server that did not rely on connected cloud services. Due to the remoteness of our mapping locations we also needed to have better ways to interact and edit OSM in a disconnected way for days and potentially weeks at a time.
This fall, thanks to the Page Family Foundation, we began work on our largest and most ambitious mapping project to date. Over the next year we will map 15km on either side of the Guinea, Sierra Leone, and Liberia borders (large PNG). This area was well mapped extensively by remote mappers during the Ebola crisis but lacks ground truthed data such as identifying hospitals, schools, churches, and other POIs. As part of this project we will establish a mapping hub in Guéckédou and develop the software and hardware tools that we need.
A couple weeks ago I joined the awesome folks from SpatialDev and Stamen in Seattle for a week of brainstorming and hacking. During the week we outlined and architected Portable OSM (POSM). As part of the project we are helping make several improvements to Field Papers and OpenMapKit as well as introducing a new lightweight OMK Server based on SimpleODK. POSM will hopefully be a very affordable (sub $300) solution to many problems for us including offline OSM API, OMK Server, and Offline Field Papers.
The project is being developed in the open on github and we are open to feedback and help.
Discussion
Comment from RobJN on 20 December 2015 at 17:57
Sounds interesting but to a non developer most of what I read is pure gobbledygook. Which is a shame because I think there is something genuinely useful behind all the speak.
Can you try and explain what you are trying to achieve in simpler language please?
Some sort of portable hardware (a phone??) that has offline version of field papers for note taking??
Comment from dkunce on 20 December 2015 at 19:44
@RobJN great question.
The goal for this project is to have both small server, about the size of a few iPhones stacked on top of each other that can be purchased that will have everything that you need to run OSM offline and then sync it back with the main OSM. We will also release all of the source code and build instructions so anyone with a little technical capabilities can deploy it on their own laptop or other similar device.
For reference we are working towards making it work on two different small servers, Intel NUC and the soon to be released BRCK+Pi
We are also overhauling the OpenMapKit website to make it easier for anyone to create and manage OMK surveys for any kind of field mapping.
Comment from GOwin on 21 December 2015 at 01:22
That’s great news! We hope we could test them out soon. Let me try to get some local organizations to try this out in the Philippines.
Comment from PlaneMad on 21 December 2015 at 06:10
This will be of immense value in india where poor electricity and internet services for large parts of the country makes projects like OSM and Wikipedia inaccessible.
Comment from PlaneMad on 21 December 2015 at 06:10
This will be of immense value in india where poor electricity and internet services for large parts of the country makes projects like OSM and Wikipedia inaccessible.
Comment from SimonPoole on 21 December 2015 at 16:50
The main issue I see is that this is being developed in its own sub-culture without any interaction with major parts of the OSM dev community. More specific OSM has had distributed editing and syncing with the central API for ages, for example with JOSM (not to mention any other editor that support offline storage and conflict resolution ie Vespucci).
However anybody who has edited over longer periods with JOSM without syncing knows that the end result can be very very messy, and the project as outlined has the potential to produce conflicts in abundance. It is unclear how the AMR is proposing to avoid this. No go Zones? Zap any non-AMR edits? ????
Comment from dkunce on 21 December 2015 at 17:57
Thanks @GOwin and @PlaneMad these are exactly the use cases that we have in mind.
@SimonPoole The idea that we are developing a sub-culture is kinda silly. We are using, improving, and contributing back to many existing OSM libraries while creating a new tool chain that makes OSM accessible to many more people. We are in active talks with the relevant developers of the projects we need to improve. We are doing everything in the open and inviting feedback. As this diary shows. Once the project is complete anyone will be able to run the offline stack for a humanitarian deployment or a neighborhood mapping party.
We love JOSM, its our go to tool for OSM editing. But have you ever lead a mapping effort over several days with multiple contributors in the field without reliable internet. JOSM isn’t the right tool to handle all of that. You need a full OSM stack replacement. We are working on a diagram that shows how all of this fits together and JOSM and offline iD are important parts to it. Vespucci is a good enough tool but it simply doesn’t our mapping needs.
Conflicts are on our mind for sure. As someone that often does field edits with mapping teams (20k) a day conflicts are not something to mess around with. Our hope is that we are building a smart way human moderated way to deal with the conflicts that arise. We are not proposing no go zones. Honestly, in the areas where we will be mapping to start the frequency of mapping is extremely low and mostly consists of large country and continent wide imports.
Feel free to let me know if you have more questions. I’ll try and answer as the development progresses.
Comment from SimonPoole on 21 December 2015 at 20:55
I wasn’t suggesting that JOSM would fit your needs, just that the basic principle is not new, and that there is a large body of experience with the issues. Matter of fact every non-broken OSM editor has to handle the problems with syncing edits to the central API and dealing with conflicts to some extent. Naturally there is some value in being able to stage edits in some fashion to avoid network problems and similar, none of the current editors really deals gracefully with that, but that is a long long way from requiring a full OSM stack replacement.