I have a question about best practices in storing geolocated form data from the ODK Central API.
User story: I am retrieving form submissions with a geopoint field from KoboToolbox and ODK Central APIs, and storing those in a GeoJSON-like format with the form fields stored in a properties array, and coordinates in a geometry array.
The KoboToolbox API offers a special metadata _geolocation field for submissions, which appears to inherit any geolocation data captured during form entry. This makes it quite straightforward to store Kobo submissions in a GeoJSON-like format: I simply pass the _geolocation_ value to geometry/coordinates.
However, from what I can tell it doesn't appear that the ODK Central API provides any special geolocation fields for submissions. So unless I'm wrong, it seems that I would need to iterate through the fields returned by the Submission XML endpoint to find anything resembling valid lat/long pairs. This isn't ideal and could run into edge cases, so I wanted to ask:
Is there currently a more straightforward way to retrieve geolocation data using the ODK Central API that I might have missed?
Are there any plans in the pipeline to add a geolocation field to submission metadata along the lines of what the KoboToolbox API offers?
The recommended way to get data from ODK Central is through the OData feed. If you're not using a system that natively supports OData, you can use the data document directly -- it's a json representation of the data. In that representation, geospatial data is represented as GeoJSON (following the OData spec).
You can also add &$wkt=true to the query parameters to request geo data as WKT. This used to work natively with Tableau but a recent forum post suggests that might not work anymore. I believe it does work natively with QGIS.
Is there a reason you've been using the submission XML endpoint? Are the docs maybe not clear enough about why and how to use the OData representation?
Indeed, I did not sufficiently investigate the OData feed and must have missed this. I see now that there is a lot of discussion on how to reference the OData feed in the ODK docs, but I was mainly working with the ODK Central API documentation on Apiary of which the bulk of the content deals with the OpenRosa format... so I reckon I was led to not look into the OData feed.
Sorry about that, we will make documentation improvements and let you know when they're ready! Hopefully you find the OData feed easier to use than it was to find.
