Conversation
|
Thanks! I'd really much rather expose a method like getGpxData rather than having a feature with magical meaning, would that be possible? |
I was trying to keep it simple (and quickly testable) From my point of view togeojson/lib/__snapshots__/index.test.ts.snap Lines 12808 to 12812 in 71b38c6 Also regarding data portability I'd rather prefer find a fairly common way of handling this. It's already quite easy to build an out-of-spec geojson (or at least without relying on other external libraries). If implemented here (as a static information) you'd at least be pretty sure that it's a quite valid thing Anyway, i think the final decision is up to you.. 👋 Raruto |
Hi Tom,
here's a draft based on: #111 (comment), that is, add a dedicated "empty" feature identified by the
"_gpxType": "metadata"property:{ "type": "FeatureCollection", "features": [ { "type": "Feature", "geometry": { "type": "Polygon", "coordinates": [ ] // eventually populated by https://www.topografix.com/GPX/1/1/#type_boundsType }, "properties": { "_gpxType": "metadata" // everything else related to https://www.topografix.com/GPX/1/1/#type_metadataType "name": "...", "desc": "...", "author": { "name": "...", "email": "", "link": { "href": "...", "text": "...", "type": "...", } }, "copyright": { "author": "...", "year": "...", "license": "..." }, "time": "...", "keywords": "...", "extensions": ?? }, { // Other features } ] }Let me know, so I'll eventually update the tests accordingly.
👋 Raruto