trackfilter pack handling of segments about gpsbabel

[robertlipe]

Yeah, our handling of track segments is not great. Do contemporary receivers even really create segments? The last GPS I bought, a Garmin 600 (650?) doesn't seem to create segments, even when passing through a tunnel, for example. It does seem like option 2 is more in line with the spirit of what 'pack' is advertised to do, though. RJL

…

On Sat, Aug 5, 2023 at 11:43 AM tsteven4 ***@***.***> wrote: The track filter pack options preserves any segment markers in the first track, and deletes any segment markers in subsequent tracks. Thus all tracks and segments after the first track are packed into the last segment in the first track. It would seem better to either: 1. preserve all segments regardless of which track they originated in 2. pack all points into a single segment gpsbabel -i gpx -f trkseg.gpx -x track,pack -o gpx -F trkseg_pack.gpx trkseg.gpx.txt <https://github.com/GPSBabel/gpsbabel/files/12267678/trkseg.gpx.txt> $ sdiff trkseg.gpx trkseg_pack.gpx <?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?> <gpx version="1.0" creator="GPSBabel - https://www.gpsbabel.o <gpx version="1.0" creator="GPSBabel - https://www.gpsbabel.o <time>2023-08-05T16:30:10.721Z</time> | <time>2023-08-05T16:31:57.829Z</time> <bounds minlat="30.046400000" minlon="-91.610567000" maxlat <bounds minlat="30.046400000" minlon="-91.610567000" maxlat <trk> <trk> <name>LOG-20020525</name> <name>LOG-20020525</name> <trkseg> <trkseg> <trkpt lat="30.062183000" lon="-91.610350000"> <trkpt lat="30.062183000" lon="-91.610350000"> <ele>1.000</ele> <ele>1.000</ele> <time>2002-05-25T17:06:21Z</time> <time>2002-05-25T17:06:21Z</time> </trkpt> </trkpt> <trkpt lat="30.062783000" lon="-91.610567000"> <trkpt lat="30.062783000" lon="-91.610567000"> <ele>0.000</ele> <ele>0.000</ele> <time>2002-05-25T17:09:55Z</time> <time>2002-05-25T17:09:55Z</time> </trkpt> </trkpt> </trkseg> </trkseg> <trkseg> <trkseg> <trkpt lat="30.052483000" lon="-91.595967000"> <trkpt lat="30.052483000" lon="-91.595967000"> <ele>0.000</ele> <ele>0.000</ele> <time>2002-05-25T18:36:48Z</time> <time>2002-05-25T18:36:48Z</time> </trkpt> </trkpt> <trkpt lat="30.052650000" lon="-91.596783000"> <trkpt lat="30.052650000" lon="-91.596783000"> <ele>1.000</ele> <ele>1.000</ele> <time>2002-05-25T18:37:52Z</time> <time>2002-05-25T18:37:52Z</time> </trkpt> </trkpt> </trkseg> < </trk> < <trk> < <name>LOG-20020526</name> < <trkseg> < <trkpt lat="30.049100000" lon="-91.593717000"> <trkpt lat="30.049100000" lon="-91.593717000"> <ele>0.000</ele> <ele>0.000</ele> <time>2002-05-26T18:55:11Z</time> <time>2002-05-26T18:55:11Z</time> </trkpt> </trkpt> <trkpt lat="30.048450000" lon="-91.594250000"> <trkpt lat="30.048450000" lon="-91.594250000"> <ele>0.000</ele> <ele>0.000</ele> <time>2002-05-26T18:56:32Z</time> <time>2002-05-26T18:56:32Z</time> </trkpt> </trkpt> </trkseg> < <trkseg> < <trkpt lat="30.048083000" lon="-91.594750000"> <trkpt lat="30.048083000" lon="-91.594750000"> <ele>0.000</ele> <ele>0.000</ele> <time>2002-05-26T18:57:24Z</time> <time>2002-05-26T18:57:24Z</time> </trkpt> </trkpt> <trkpt lat="30.047500000" lon="-91.595450000"> <trkpt lat="30.047500000" lon="-91.595450000"> <ele>7.000</ele> <ele>7.000</ele> <time>2002-05-26T18:58:40Z</time> <time>2002-05-26T18:58:40Z</time> </trkpt> </trkpt> </trkseg> < </trk> < <trk> < <name>LOG-20020527</name> < <trkseg> < <trkpt lat="30.046633000" lon="-91.596600000"> <trkpt lat="30.046633000" lon="-91.596600000"> <ele>0.000</ele> <ele>0.000</ele> <time>2002-05-27T19:00:22Z</time> <time>2002-05-27T19:00:22Z</time> </trkpt> </trkpt> <trkpt lat="30.046400000" lon="-91.597650000"> <trkpt lat="30.046400000" lon="-91.597650000"> <ele>0.000</ele> <ele>0.000</ele> <time>2002-05-27T19:01:41Z</time> <time>2002-05-27T19:01:41Z</time> </trkpt> </trkpt> </trkseg> </trkseg> </trk> </trk> </gpx> </gpx> — Reply to this email directly, view it on GitHub <#1152>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACCSD37EQASV5ORPAHQTJGTXTZZ3JANCNFSM6AAAAAA3FKBNLQ> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[tsteven4]

I have a very new garmin device. Natively it records fit files which include stop and start events. These can be triggered manually or automatically. We translate these into track segments (garmin_fit -> gpx). The gpx available directly from garmin only includes one track segment even if there are multiple stop starts in the fit file.

In this case I think preserving all the segments makes more sense. This would result in a change to a reference file, trackfilter3.gpx. There are other cases, e.g. merge, were we intentionally drop the segment markers, as it isn't clear what would should make up a segment in the merged output. So if pack preserves segments it would be possible to delete them by
-x track,pack -x track,merge.

For pack, we say we join the tracks, but don't mention how segments are handled. From our documentation:

This option causes all tracks to be appended to one another to form a single
track.

From the gpx 1.1 xsd:

A Track Segment holds a list of Track Points which are logically connected in order. To represent a single GPS track where GPS reception was lost, or the GPS receiver was turned off, start a new Track Segment for each continuous span of track data.

[tsteven4]

OTOH, isn't option 1 what trk2seg does?

[GPSBabelDeveloper]

OK. Sold. I think either is defensible for us, so no strong conviction here. While my trekking days are mostly over, I was always more of a customer of their "for outdoors" lines (Oregon, etc.) than their "into fitness" lines. For a long time, Garmin Fit was our most squeaky wheel. I don't know if we finally got all the corners nailed down in that or if there's been a drop in use via stronger mobile app integration. Oh, and no, I think trk2seg makes a new <trk> out of every </trkseg><trkseg> vertex. Sed -i "s#</trkseg><trkseg>#</trkseg></trk><trk><trkseg>#g Sorta.

…

On Sat, Aug 5, 2023 at 4:33 PM tsteven4 ***@***.***> wrote: I have a very new garmin device. Natively it records fit files which include stop and start events. These can be triggered manually or automatically. We translate these into track segments (garmin_fit -> gpx). The gpx available directly from garmin only includes one track segment even if there are multiple stop starts in the fit file. In this case I think preserving all the segments makes more sense. This would result in a change to a reference file, trackfilter3.gpx. There are other cases, e.g. merge, were we intentionally drop the segment markers, as it isn't clear what would should make up a segment in the merged output. So if pack preserves segments it would be possible to delete them by -x track,pack -x track,merge. For pack, we say we join the tracks, but don't mention how segments are handled. From our documentation: This option causes all tracks to be appended to one another to form a single track. From the gpx 1.1 xsd: A Track Segment holds a list of Track Points which are logically connected in order. To represent a single GPS track where GPS reception was lost, or the GPS receiver was turned off, start a new Track Segment for each continuous span of track data. — Reply to this email directly, view it on GitHub <#1152 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC3VAD52534QCQVL2JNR5U3XT233DANCNFSM6AAAAAA3FKBNLQ> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[tsteven4]

This was fixed in #1155