Reading and converting gx:coord/gx:Track to Geometry

[agent10]

• I agree to follow the project's code of conduct.
• I added an entry to the project's change log file if knowledge of this change could be valuable to users.
  • Usually called CHANGES.md or CHANGELOG.md
  • Prefix changelog entries for breaking changes with "BREAKING: "

---

This PR adds an initial support of gx:coord/gx:Track tags from KML extension.
This was also partly mentioned in #62.

[pjsier]

@agent10 thanks for the PR! For #30 we're hoping to create it first as intermediate Track elements, and then have the ability to convert those to geometries. Here it looks like we're parsing to geometries directly, could you make that change? And then I'm happy to take a closer look

[agent10]

@pjsier sure, this is my first time dealing with KML directly but I'll try! Thx!

[agent10]

@pjsier Updated. I added an intermediate Track element.
Let me know if there is anything else you want to improve here.

[pjsier]

Sorry for the delay! A few more things I didn't mention initially

• We'll need to add this to the overall Kml enum. That way, it's possible to parse KML regardless of the top-level element
• We also need to add Track as an element that can be converted directly into geo_types::Geometry. That way it's straightforward to pull all geometry types out into something that can be used with the geo_types library

[pjsier]

Is there a use case for converting to kml::LineString over geo_types::Geometry::LineString? It seems like that's what we'd be looking for and is easier to work with

[agent10]

@pjsier i'm looking into this now, and in my case I have KML files where Track is inside Placemark, similar to the example I made for unit test
But the Placemark uses kml::Geometry internally, so that's why I've initially added a conversion to kml::LineString

Yeah, I'm going to add the general conversion to geo_types::Geometry::LineString but not sure how to deal with the use case above, pls advise..

[pjsier]

Got it, thanks for flagging that! I think that also highlights a gap we can clean up here.

Right now we're only parsing child elements in geo_types::Geometry<T>::try_from for Kml::Folder, Kml::KmlDocument, and Kml::Document. Kml::Placemark is only checking geometry like you mentioned here.

I'll open a quick PR in a bit, and then you should just be able to add a branch to the segment in TryFrom that adds this specific element

[pjsier]

@agent10 on second though, I looked into this more, and it would be a much more substantial change. To keep this simple and avoid mixing the items up too much I added a comment below, and then in a separate PR I might need to rethink how Placemark is implemented

[pjsier]

I think we should be able to reference .coords here instead of the Track itself since LineString already has a From implementation for Vec<Coord<T>>