Export spatial data as WKT (Well Known Text) in CSV

Suggestion Box
1

What is the general goal of the feature?

Make spatial data directly compatible with existing GIS programs and spatial databases. Currently the spatial data is a string of “lat lon elevation accuracy.” This format is not recognizable by QGIS. In GIS programs, the WKT standard, and also in spatial databases such as PostgreSQL, the X and Y values are swapped. This means that the values from kobo have to be converted either manually or via scripts and the elevation and accuracy dropped. Also, there is no point in not truncating the decimal output of the accuracy value to 2 or three places if the collecting device returns a large amount of decimal places. (Ideally, the lat/lon decimal values could themselves be truncated automatically based on the accuracy value for each position).

What are the most likely user stories for how and when this would be used by someone on your team?

Susan collects a variety of point, linear, or polygon features easily in the field using her Kobo form. She then exports the data with the spatial information in the WKT format. This is just text, so it exports to one CSV file with a single WKT column for any of the three spatial data types as POINT (), LINESTRING () or POLYGON (). Without having to tediously convert anything, she can then simply open the exported CSV file in QGIS as points, lines, or polygons, or three times, one in each spatial type resulting in three open layers in QGIS.

How useful would this feature be to other users or organizations?

Anyone who uses desktop GIS or spatial databases and wants to quickly map their data.

What can you contribute to making this feature a reality?

Testing, feedback, sample data.

2

I agree totally with this suggestion by lymankj. In fact I would go further, I suggest directly to store spatial data as WKT. Benefits are too good to ignore this idea.

1 Like
3

Yes! WKT is a very handy open standard for expressing spatial data in text. It’s also useful because multiple spatial types (point, line, polygon, etc) can be expressed in the same CSV or spreadsheet file instead of split across multiple data files by type as is normally the case in GIS data files, which makes it ideal for Kobo form data.

For example, if a Kobo survey was exported as a CSV and included multiple WKT types, a user could then first open this in QGIS as a point layer, then open the file a second time as a new layer as a line layer, and even a third time as a polygon layer. Then if any corrections or edits needed to be made the data, it would just be done in the one CSV in a spreadsheet program and the changes would be reflected instantly for all three layers in QGIS.

1 Like
4

Hi @lymankj, @santipesta,

Wanted to add this post made by @santipesta here (as the post is related with the suggestion outlined here):

Have a great day!

5

Hi @Kal_Lam! Thanks for linking this suggestion with my other post!

I think it is here where the discussion must follow, as it actually is a suggestion.

About existing ways for Exporting and Downloading Your Data: This is great! Yet, I think it would be very useful to be able to store (or at least to export) geodata as points, lines and areas in WKT format (or even one of the same family, like WKB, EWKT, EWKB), because geopoint, geotrace and geoshape all need some processing skills to load it in a map or a GIS, like explained in Exporting and uploading your data to GIS software and there is not any known tool to do it… vs little or no effort to:

  • load WKT directly into a map like leaflet (Wicket, omnivore) / openlayers (search for Create features from geometries in WKT format)
  • store WKT (almost) directly in any database with spatial data capabilities. WKT, EWKT, WKB, EWKB are all well-known and widely used formats and all spatial database engines undertands it. PostGIS for example.
  • load WKT easily into a GIS tool (just googling “load WKT qgis” it throws a lot of plugins and options)
  • convert WKT easily into another expression: GeoJSON, SHP, KML… because many tools exists to do this
  • and all the advantages to use standard, well-defined and well-known formats as interoperability, compatibility, robustness, etc etc…

I have very little experience in the vast universe of GIS tools and geodata, but as I go further and deeper, I only read and hear about WKT, GeoJSON, KML, SHP… but I had never seen geopoint, geotrace and geoshape format before.

I understand that accuracy is an information that is ignored in in all other formats, and it is something important. Although many solutions may arise given the opportunity. Or maybe exporting all geodata (areas and lines included) to WKT, GeoJSON or KML is enough, and simple to implement.

I am sure that there is something I am missing, and that exists some good reason for geopoint, geotrace and geoshape implementation to represent geographic information.

I would be glad to be hearing from you all and continue with this thread.

Finally, many many thanks for the openness and for giving us the space to comment and suggest things.

PS: I had to delete some links for being newbie :frowning:

1 Like
6

Hi @santipesta,

Thank you for providing a detailed explanation. Will document the same at the moment and also update the same if i see any new threads in this post.

Have a great day!

7

Nope. Its just the format that happened to be chosen back in the day… :slight_smile: There’s nothing compellingly advantageous about it.

standards

If you are curious, there are ways you can generate other GIS formats from within your form; they are a bit messy, but if you are really desperate…

KML: ODK geoshape/geotrace/geopoint to KML - Showcase - ODK Forum
WKT: ODK geoshape/geotrace/geopoint to WKT - Showcase - ODK Forum
GeoJSON: ODK geoshape/geotrace/geopoint to GeoJSON - Showcase - ODK Forum

2 Likes
8

I should have imagined. :sweat_smile:

Excellent. Thanks! I definitely will have to workaround this anyway. Still not desperate, thankfully. We will surely share the experience.

2 Likes