pdhoopr / gps-to-gpx Goto Github PK

This is blocked by eslint-config-airbnb. Waiting on them in this issue to update their peer dependencies for v3.

Hi,

In my particular use case, I always have all the keys defined but the value is not always defined. Typically, my waypoints can look like

[{ elevation: 10, ... }, { elevation : null, ... }, { elevation: 20, ... }]

With the current code and the check for hasOwnProperty, the property is always defined, so the <ele> tag is always emitted (with empty value).

What about switching the hasOwnProperty test to point[eleKey] !== null && point[eleKey] !== undefined for example? This would avoid emitting such values.

I could also handle this by pre-filtering my data, not sure what sounds best for you.

Thanks!

Hi,

Actually, I've just noticed the current version of the lib output a GPX 1.1 file (which is latest version). This is perfectly fine and works well except for the recently added course field. Actually, course is defined in GPX 1.0 spec: http://www.topografix.com/gpx_manual.asp.

However, it seems to have disappeared from the GPX 1.1 spec: https://www.topografix.com/gpx/1/1/.

Not sure what is best to do here, either:

• Leave it as is, with course element in GPX 1.1 which might not be valid.
• Move to a plain GPX 1.0 file rather than GPX 1.1 (I think there is only the header to change, not 100% sure though), to support course.
• Drop support for course.

Best,

Hi, this is a wonderful tool for importing tracks, but it would be even better if it could also highlight individual POIs with identifying icons/text. Would that be hard to implement?

I was wondering if the input array could have another element indicating that it was a POI rather than a point on a track, e.g. "name" and it could generate a "wpt" instead of a "trk".

Thanks!

Hi,

I would like to use track point extensions in generated xml files so I can add heart rate, candence and other metrics. It should look like this:

<trkpt lat="54.8591470" lon="-1.5754310">
<ele>29.2</ele>
<time>2015-07-26T07:43:42Z</time>
<extensions>
<gpxtpx:TrackPointExtension>
<gpxtpx:atemp>11</gpxtpx:atemp>
<gpxtpx:hr>92</gpxtpx:hr>
<gpxtpx:cad>0</gpxtpx:cad>
</gpxtpx:TrackPointExtension>
</extensions>
</trkpt>

It is simple to implement:

if (point.extensions) {
      const trackExtension = trkpt.ele('extensions').ele('gpxtpx:TrackPointExtension');
      Object.keys(point.extensions).forEach((key) => {
        trackExtension.ele(`gpxtpx:${key}`, point.extensions[key]);
      });
    }

Could you add it to this library?

This is a minor detail, but converting Date objects to ISO 8601 would be nice.

As of now, if you pass a Date object, you end with a UNIX TIMESTAMP. You can obviously do a .toISOString() previous to passing the dates, but handling it automatically would be better.

ActivityName from options is now used only in Track-level name-field and in the top level metadata name-field is always "Activity". However it appears that at least some Garmin devices use top level metadata in the UI and therefore always present GPX-tracks generated by this library with name "Activity".

I know very little of GPX-format however took a quick look at some other GPX-tracks e.g. those produced by Strava Routes, all those seemed to have same name-field both at the top level and track.

Propose either a new options-field is added for the top level name-field or if it's in line with GPX-format just use existing ActivityName.