ODK geoshape/geotrace/geopoint to GeoJSON

Within the framework of a project that will suppose Mobile spatial data collection in the field, I made a battery of tests and compare different tools to make the data collection and above all the spatial data management as simple as possible.

The accessibility to the network is not guaranteed and we cannot yet rely on a GIS/DBA officer to make advanced post-processing. I don’t know what type of spatial data is to be collected. According to this context, I’ve deployed an architecture based on ODK (collect, Briefcase and Aggregate using VM) . I’ve also tested ONA server to aggregate the data. I’ve set up a XLSForm that allows users to collect any type of geometry (point – map and GPS, trace and shape) in a single form. An spatial object is mandatory.

Then, I try to export and use data in QGIS. As said on many treads (i.e. here), storage of the geometry into aggregators is not standard and KML export doesn’t provide optimal results.

At the moment and from what I’ve tested, the @ggalmazor's excellent, very convenient and flexible Briefcase tool (I use v.1.16) is the only one which allow GeoJson export.


But I was also inspired by the recent and excellent showcase from @Xiphware, who show how to extract and deal with the coordinates of every point of a spatial object within an Xform. So, I decided to adapt a bit his XForm to have a GeoJSON representation of every type of geometry directly in a single form. I reused the methodology and steps share by @Xiphware so nothing new wheel is reinveted only the results is different.

Few things to know :

  • Geopoints : latitude and longitude of any GeoPoints are calculated in two separated columns (obs_geopoint_lat/obs_geopoint_long), doesn’t matter if the point is picked on the map or taking by GPS)

  • GeoTrace and GeoShape : in GeoJSON, each coordinates block is separated by a comma (i.e : [[-4.445633258207607,36.69798465595203,0.0], [block2.]) except for the coordinates block of the last point that should end with the bracket. This is managed through a condition on the « alt » column based on the position of the point.

The results of the GeoJSON column can be pasted into a tool like https://geojson.io or directly saved in geojson file and imported on QGIS. Right now, we have one file per submission.

Here, the XForm

survey-shop_geojson_demo.xlsx (11.4 KB)

I don’t know but I hope these may be useful of some other use. Maybe it’s not the faster way to convert the geometries to GeoJSON (prefer obviously Briefcase) and the suggested calculation could be much more efficient. But OK, it works and allows to retrieve GeoJSON structure and deal with it through our GIS desktop,


Awesome! I'm so happy the KML stuff inspired you to build upon it. :slight_smile:


This is very interesting to me. I've been battling with a form that can record point, geotrace or geoshape (depending on the user choice). All three geometry types can be present in the output csv (provided it is a flat one table output). If I understand correctly this example form will covert the coordinates to geojson format. Please let me know if this is the case.

The Python script I'm writing will look for any geometry in an output .csv, process it to geojson and allow the result to be imported into QGIS. If all three geometries are present a separate geojson will be created for each geometry type (point, line, polygon).

The perceived benefit is that attributes will be present in the output files. GeoJSON is much easier to export to shp or other file type and still maintain the attributes.

Does the kml output mentioned above maintain attributes from the ODK file and would the code I'm writing be of use?