Record GPS data according to WKT specification

User Support Form Building
1

I have been exploring ways to circumvent the issue reported here Geotrace/Geoline + Geoshape support, and come up with the idea of generating EWKT (Extended Well Known Text) notation from the pairs of coordinates of a geotrace or area, and, from there, the actual geometries.

My approach would be a simple text concatenation to be executed in excell or GIS software. Something like CONCATENATE(’(‘SRID=4326;LINESTRING(’ || coordinate pairs of geotrace||’)’)’)

The problem is that the coordinate pairs that make up the line are NOT separated by commas as expected by WKT making it very difficult to parse. Examples below:

Kobo Collect: 23.2233 54.2233 23.3344 54.334565 23.44556 54.22345 …
WKT format: 23.2233 54.2233, 23.3344 54.334565, 23.44556 54.22345, …

Is there a reason for this? If not I would suggest to have the coordinate pairs separated by comma because that makes it much easier to spatialize data in GIS environment.

Thanks

2

If you are wishing to generate WKT formatted data, from the native geotrace/geoshape data format used in ODK Collect/KoboCollect, then you may be interested in reading this thread: https://forum.opendatakit.org/t/odk-geoshape-geotrace-geopoint-to-wkt/21062

1 Like
3

Thanks for your suggestion. In the meantime I found a more straightforward solution in the form of a recently developed plugin for QGIS: https://github.com/ResilientDar/odktrace2wkt

However my suggestion stands: spatial data should be recorded using known standards, it makes everyone’s life easier!

Cheers

1 Like
4

To be fair, geopoint/geotrace/geoshape - as used in Kobo - are in fact a ‘standard’ inherited from the ODK XForms spec (ie not something Kobo dreamed up!). But how they originally came about in ODK spec is probably a good example of…

standards

:slight_smile:

5

:smiley: good one!

In any case, if this debate ever sparks again in the future I will happy to give my 2 cents to that discussion.

6

Not promising anything mind you… but would you prefer WKT, KML, or GeoJSON? (or some other of the 14 competing GIS standards…)

2 Likes
7

Thanks for considering it. I understand we are just in the plane of sharing ideas, but if I am allowed to dream this what I believe would serve most of the use cases:

1 - In the case of points, you would still be getting a column for lat and another one for long (this is to ensure simple workflows folks have in place where you simply generate geometries from a column with x and another column with Y are not disrupted), but the location column would be storing the point in the form of EWKT

2 - For the cases of lines and polygons, only one column would be needed with the geometry stored according to the EWKT notation

3 - Finally, when it comes to download the data, an option to download the survey as GeoJSON could be added. The GeoJSON has some interesting advantages for spatial applications:

  • Every GIS package that I know of reads GeoJSON
  • Contrary to KLM where attribute table management is not straightforward, GeoJSON manages the relation between geometries and attributes quite well, the latter becoming a plain table when the GeoJSON is consumed in a desktop GIS
  • Last but not least GeoJSON is friendly format when it comes to web applications. Javascript libraries like OpenLayers, leaflet and many others can read GeoJSON without the need of parsing it first.

As a last note, having the geometry stored as an EWKT text string in would also be interesting if you are pushing your CSV/XLS table into a spatial database like PostGIS where a column storing EWKT could be used to generate geometries.

1 Like
8

Note, if you merely want to have the components in distinct ‘columns’ (I assume you are extracting the submission data as a CSV or equivalent ‘flattened’ format…) then you can readily accomplish this by just adding some additional suitable calculations to your form. eg

type        name      calculation
-----------+---------+-------------------------
geopoint    geopoint    
calculate   lat       selected-at(${geopoint}, 0)
calculate   long      selected-at(${geopoint}, 1)

so lat and long will show up as separate columns in your extracted CSV.

Similarly, you could add a calculation to generate a WKT POINT representation of your geopoint; eg

calculate   location  concat('POINT (', ${long}, ',', ${lat}, ')')

where, again, the location calculation would show up as another distinct column.

Since there are just (hidden) calculations, they wont actually appear in the form to the user, but they will get submitted in the final result.

Unfortuantely, as you can see in my earlier link, performing (conversion) calculations on geotraces and geoshapes is a lot messier…

1 Like
9

I see your point and I agree that in the case of points nothing has to change. But if at some point a decision is made to tackle the current limitations in the storing of lines and polygons, then, for the sake of consistency, the same approach should be valid (imho) to all geometry types.

1 Like