Guidance/tooling to convert from KML/shape files to standard formats

[lgs85]

A key piece of initial feedback from our pilots has been that potential publishers are mostly storing their geographical data as KML or shape files, with feature data stored elsewhere. This supports what we found in our supply side research. In order to boost chances of adoption it is clear that we will need to make it as easy as possible for publishers do the mapping from their existing files/databases to the standard formats. Ideally this would be in the form of some sort of generic tooling and accompanying guidance, in addition to direct support for publishers. We should consider what such guidance and tooling might look like.

This has been described as a 'major priority' by one key stakeholder.

[duncandewhurst]

Noting that @stevesong is working on this in https://github.com/stevesong/kml2ofds

[hydratim]

So, one of the big problems with this is that a lot of these KML files don't store the path properly as a singular linestring, and instead store every line segment (i.e. each singular pair of coordinates) as linestrings, some of which are back to front, and some don't start/stop at the same coordinates and instead overrun eachother slightly.
This makes implementing a KML 2 OFDS implementation that reliably works in all cases somewhat difficult.
Furthermore as a lot of GIS packages will only export a single span per KML, you have to re-merge the Spans and Nodes - which cannot be fully automated, as you might have multiple spans that share the same path for part or all of the run.

[stevesong]

Hi Tim. I have been working on a script to convert KML to the OFDS standard and my main take-away is that people do some crazy things with KML, sometimes intentionally but more often unintentionally. You can see the logic I have tried to follow in the readme of the repo. Back to front strings are a huge PITA, as are crossed strings or strings that intentionally loop. However, I think it is possible to do something that would work for 80-90 percent of KML maps.

I think one possible way forward would be to make the conversion bi-directional so that OFDS data could be re-encoded as meta data in KML; folk could improve the map (fixing some of the more egregious examples above) in Google Earth; and re-convert it to the OFDS output.