Thanks for laying this out @duncandewhurst. Am coming into this with minimal background so feel free to ignore if out of scope. One thing I noticed is that flatterer seems to deal with geojson, including points and linestrings, quite well already. Here's what an example output csv looks like:

More generally, my view is that for the vast majority of applications that would use the geospatial data, it will be easier to import a geojson file directly, so we shouldn't worry too much about presenting lat/long in analysis-ready format in a csv export. That being said, I don't love the idea of leaving the geospatial data out of the csv export entirely, as this could cause confusion e.g. if the csv conversion is used for database imports. So option 1, or something like the flatterer output if that's an option, might be the best bet.

Thanks, for the reminder about flatterer, @lgs85. I've opened a separate issue (#14) on deciding what tool to use so that we can keep this issue focused on the desired modelling.

More generally, my view is that for the vast majority of applications that would use the geospatial data, it will be easier to import a geojson file directly, so we shouldn't worry too much about presenting lat/long in analysis-ready format in a csv export. That being said, I don't love the idea of leaving the geospatial data out of the csv export entirely, as this could cause confusion e.g. if the csv conversion is used for database imports.

I agree that GeoJSON would be easier for many use cases but that it would also be desirable to have the same information available in each publication format.

I don't think we should use Flatterer's representation of geometry_coordinates since it shares the same usability issues as Flatten Tool's representation and, arguably, it's worse since users would also need to handle the extra set of square brackets.

The W3C's Spatial Data on the Web Best Practice 8: State how coordinate values are encoded is a useful reference for this issue.

Coming back to this, I see no benefit in representing points as separate long/lat fields and lineStrings as WKT, as i) very few users will want to use just node data, so ii) they will have to parse the WKT for lineStrings anyway, iii) representing both as WKT has the advantage of consistency, which iv) makes conversion and conversion tooling easier.

Therefore suggest we represent both points and lineStrings as WKT.

For the Alpha, we'll use the default format provided by Flatten Tool and look to update the tool to provide WKT format in the Beta.

Feedback from the World Bank's infrastructure map team is that WKT is expected for CSV files so I think we do want to use WKT for both point and linestring geometries.

@Bjwebb, I've created a draft PR with updated CSV examples showing what I expect the WKT format to look like. Please could you check that you're happy with it from a Flatten Tool perspective?

Edit: Noting that I've replaced the whole Node.location and Span.route objects with WKT fields, rather than only replacing Node.location.coordinates and Span.route.coordinates, since the WKT format encodes both the geometry type and the coordinates.

This looks like what I'm expecting.