Benchmarking: MDC Tools with strong GIS component
CartONG is regularly commissioned by its partners to collect data in the field. While many of those missions are surveys based on household interviews and mostly focus on beneficiaries and their needs and risks – we also frequently support data collection on facilities and infrastructures. Collecting information on facilities often requires a different approach: while the logic of the survey form requires less complex patterns, the importance of the geographical dimension is accentuated. In many cases, we simply need the position of a certain facility (the location of a borehole for example). In those cases, the collection of points, as possible in most standard MDC tools, is enough. But there are other cases where we want to collect an area polygon for example when we look at entire refugee camps or when we want to collect a line to map roads and indicate their conditions.
To collect such data is often hard or impossible with standard Mobile Data Collection tools as the options to collect geographic information and output such data in standard formats for use in geographic software are limited. Therefore we recently conducted a benchmarking to compare a few geographic MDC tools.
Apart from the simple data collection tools we presented in our blog post from March (which are useful especially for non-experts and individual data collections) we also looked at tools that allow larger, standardized collections of geographic and attribute data. While we knew some of the tools already, the benchmarking still held surprises for us. Two of the surprise–tools we want to present in this blog post:
- ODK Collect – a standard MDC tool with strong geographic features
- OpenMapKit – an add-on to ODK Collect if you want to improve OpenStreetMap data
There are many reasons to use ODK Collect and recently its capability to collect geographic data has become one of them. Since version 1.4.12 of ODK Collect, released in October last year, support for offline mapping is available. This includes choosing between basemaps as well as support for additional question types to collect area or line features by either clicking on the basemap or tracing the phone at regular intervals. Those question types are called GeoShape and GeoTrace respectively. They complement the GeoPoint question type which was available before.
In the “General Settings” you find a “Mapping” section which allows you to choose between different basemap styles based on Google Maps (Streets, Satellite, Terrain, Hybrid) or OpenStreetMap which includes designs such as the standard OSM but also Stamen or CartoDB (Positron or Dark Matter) which help with the orientation on the map whenever a geographic question is asked in a survey.
The GeoTrace and GeoShapequestion allow the user to collect polygon or line features. With a GeoShape question the user can create a polygon by indicating the corner points clicking on the map. The shape is then saved by including the latitude, longitude and altitude of each point. The GeoTrace question on the other hand allows creating a polygon or line by tracking one’s movements on the map. The tracking points can be taken manually (on click) or automatically every 1 to 30 seconds.
Hence, the ODK Collect app can be a useful tool for collecting geographic data during a survey. Nevertheless, there are still quite a few weaknesses. The main problem is that the app has not yet caught up with the new development. For example, while there is a button in the map interface of the app that suggests you can add “offline basemaps”. However, there is no explanation on how to add such offline tiles. Furthermore, the format in which the GeoTrace or GeoShape questions are stored cannot simply be imported into any standard GIS software. While most ODK-like servers allow exporting GeoPoint questions in KML format they won’t necessarily allow to export GeoTrace or GeoShape questions. For example the Kobo server’s KML export option only works for GeoPoint questions. Aggregate on the other hand can export all three geo-questions types as KML. The CSV output which includes a column on location contains the necessary values but not in any standard format (such as the “well known text” format used by QGIS). Hence the output CSV needs to be converted before it can be used. One conversion tool for example was developed by the GeoODK team: http://geoodk.com/mdk_howto.html. Nevertheless, the additional steps make it rather inconvenient to work with GeoShape or GeoTrace questions. So we are still hoping for a few more improvements to make the features of this tool more user friendly for geographic collections.
While we had heard of OpenMapKit (OMK) before, the benchmarking was our first chance to get to know this application which was developed by the team of the American Red Cross specifically for the humanitarian sector. This app is, in fact, an extension of ODK Collect allowing you to easily collect data which you later want to share via OpenStreetMap (OSM) . The idea for OMK is that you can combine two surveys: One standard ODK survey which you don’t necessarily want to share with anyone, and, in addition to that, one survey to update or improve data on OSM such as details on buildings – like the type of building (for example offices, shops or residential buildings) or the roof material of the building, the number of floors of the building or any other details on the building that you might be interested in.
If you want to combine those two surveys – ODK and OMK are the way to go. Behind the scenes your standard ODK survey gets an extra set of tags (within a new tab in the XLS form) to reference questions that are intended for OpenStreetMap.The enumerators start their survey in ODK and when the OSM type questions come up, they are prompted to open OpenMapKit. They fill in those OMK questions and once they are done, they automatically switch back to ODK Collect to finish the survey.
What is quite different from your standard ODK workflow however is your server interface: you will use a POSM (portable OSM) server which can be used either entirely offline or set up in the cloud. This is the staging ground for your data and forms. It is to the POSM server that you download the OSM data for your area of interest, you also upload your XLS forms to the server. After a collection your data is send to the POSM server and you can view the details in a table, submit the OSM tagged details to OpenStreetMap and download the surveys in CSV format.
While this app clearly fills a gap as it allows you to easily improve OpenStreetMap data in the field, it also has some weaknesses. The app enables you to add nodes (POI) and update the attributes of the map features but it does not allow you to add line or polygon features directly through the application. So be sure to start your project with a Mapathon to have all necessary building polygons available on the phone before you go to the field. The other disadvantage over existing MDC tools is the need of a POSM server. While clearly the server does everything you need: staging the forms and data, allowing submissions to OSM and downloading of information, the server setup is quite complex for the ordinary user. A developer is needed for the setup and potential problem fixes. We had the help of the American Red Cross developers who have been very accommodating and helpful. They set up the server for us and explained us the procedure. But for full projects it is difficult to imagine working with a POSM server without having a developer in-house who can quickly intervene whenever necessary.
OpenMapKit and ODK Collect were definitely the most exciting and new tools for us in the benchmarking on Mobile Data Collection tools with strong GIS components. To read the entire benchmarking and find out more about other tools we tested, such as the simple data collection tools we presented in the last blog post or tools such as GeoODK, GeoDataCollect, Survey123 & Collector for ArcGIS you can download the report here.