'Import rider times from GPX...' wizard

[kimble4]

A wizard that reads a GPX track recorded by a rider during the race and attempts to determine their lap times.

Uses the GPX course to determine the lap length and location of the finish, interpolates the recorded track to one point per second, then presents a filtered list of trackpoints and likely crossings of the finish line. These can then be individually selected for import into the rider's lap times (where they will be filtered in the usual manner).

Intended as a backup for when there are problems with a rider's timing tags (or the spotter loses track of their laps), but the rider was recording the race with their GPS receiver. My tests suggest that if you have a high resolution GPX and a reference lap time(s) to adjust the clock offset this can get the times to within a second or two of the RFID system, but it would still be useful to determine the lap count with far worse precision.

Conceivably if you had a lot of patience and trusted riders not to meddle with their recordings you could time a small race this way (as usual, some human input would be required to resolve close finishes), but I wouldn't want to try to manage that at any scale.

[esitarski]

My primary concern is that this is a significant amount of code to write, test, document, support and maintain for a relatively small problem. It also relies on the rider having a GPX device with the ability to produce the GPX file at the race. This reduces the "success factor" even more. A pragmatic way of handling the "unknown rider" case is to find a "known rider" who was riding "close to" the unknown one. Then: - Bring up RiderDetail on the "known rider". - From RiderDetail, press *Edit...*, then *Copy Rider Times to New Number... *When prompted, enter the "unknown rider's" bib number. This duplicates the times of the "known rider" to the "unknown rider". - Edit the last duplicated time of the "unknown rider" to get a final finish time (as best as you can). Not perfect, but you get a working solution with a lot less effort. To reduce tag failures, it's a good idea to check the tags at race check-in (including using RaceDB, which supports self-serve rider check-in with tags).

…

On Thu, Mar 2, 2023 at 6:25 PM Kim Wall ***@***.***> wrote: A wizard that reads a GPX track recorded by a rider during the race and attempts to determine their lap times. Uses the GPX course to determine the lap length and location of the finish, interpolates the recorded track to one point per second, then presents a filtered list of trackpoints and likely crossings of the finish line. These can then be individually selected for import into the rider's lap times (where they will be filtered in the usual manner). Intended as a backup for when there are problems with a rider's timing tags (or the spotter loses track of their laps), but the rider was recording the race with their GPS receiver. My tests suggest that if you have a high resolution GPX and a reference lap time(s) to adjust the clock offset this can get the times to within a second or two of the RFID system, but it would still be useful to determine the lap count with far worse precision. Conceivably if you had a lot of patience and trusted riders not to meddle with their recordings you could time a small race this way (as usual, some human input would be required to resolve close finishes), but I wouldn't want to try to manage that at any scale. ------------------------------ You can view, comment on, or merge this pull request online at: #106 Commit Summary - 3fa7dbb <3fa7dbb> Initial proof of concept - 990ffd2 <990ffd2> Default offset based on local timezone - efb0d7c <efb0d7c> Functionally complete - 3412981 <3412981> Add help - 62f19ed <62f19ed> Interpolation - e43dd6c <e43dd6c> Update help - 2c2d739 <2c2d739> Remove test filename/bib - 8a753d1 <8a753d1> Tidy up prompt text - a97c14b <a97c14b> Merge branch 'esitarski:master' into kimble4-importgpx - 63d54ad <63d54ad> Error message if no race - 93b6c19 <93b6c19> Process lap length, assorted GUI improvements - 8a19fd0 <8a19fd0> Update help - 8c7931e <8c7931e> Fix colouring of lap times - d349608 <d349608> Merge branch 'esitarski:master' into kimble4-importgpx File Changes (6 files <https://github.com/esitarski/CrossMgr/pull/106/files>) - *M* GpxImport.py <https://github.com/esitarski/CrossMgr/pull/106/files#diff-055ccb8efd9f3821baf221882f1df1493edc54d02c9224618178f98e88d93ca4> (2) - *M* GpxParse.py <https://github.com/esitarski/CrossMgr/pull/106/files#diff-c0c8578fc677080bf5a365698d7f1ce390843425806dc45f4d061d5a4ecd5f9f> (2) - *A* GpxTimesImport.py <https://github.com/esitarski/CrossMgr/pull/106/files#diff-41d5ff90a05b50d22700beb0c680458db4cb6de08a700849795bc03242c0ebbc> (575) - *M* MainWin.py <https://github.com/esitarski/CrossMgr/pull/106/files#diff-5a5f46554ef499afef996c63f6a0022d0a7e23bfe5636bf5084cff5a35c84db4> (28) - *M* helptxt/Menu-DataMgmt.md <https://github.com/esitarski/CrossMgr/pull/106/files#diff-535776536d0985d0a28ae51b0853436875fd1f857a25c34fa0cc7626bd63125d> (12) - *M* requirements.txt <https://github.com/esitarski/CrossMgr/pull/106/files#diff-4d7c51b1efe9043e44439a949dfd92e5827321b34082903477fd04876edb7552> (1) Patch Links: - https://github.com/esitarski/CrossMgr/pull/106.patch - https://github.com/esitarski/CrossMgr/pull/106.diff — Reply to this email directly, view it on GitHub <#106>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABGXKNWWUMWINCGNYGHYCDW2ET5DANCNFSM6AAAAAAVN7TUXM> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

-- Edward Sitarski

[kimble4]

Fair enough, tbh. This was something I've been wanting to try since a generator failure left us with no tag reads for half an endurance race a couple of years ago. In that case we painstakingly reconstructed the lap count based on a couple of GPX recordings and people's memory of when they lapped who. (While the generator was quickly restarted, the underlying problem was a combination of a terrible USB-Ethernet dongle that wouldn't bring its interface back up unless the USB side was hotplugged, and a lack of technically competent volunteers to supervise the timing system - they saw a screen full of lap times and didn't recognise the significance of them all being yellow.) I'm surprised this works as well as it does, but I can see how it would be of marginal benefit for larger scale events where you don't have the problem of the timing team also wanting to be in the race, and where riders lapping each other is a relatively infrequent occurrence (so copying another rider's times is a simple solution). The dongle has been retired since the purchase of a new laptop with integrated Ethernet, and we've done some work on battery backup for the tag reader, but I'll keep this in my fork as a talisman against future improbable failures... Kim.

…

On 07/03/2023 17:58, Edward Sitarski wrote: My primary concern is that this is a significant amount of code to write, test, document, support and maintain for a relatively small problem. It also relies on the rider having a GPX device with the ability to produce the GPX file at the race. This reduces the "success factor" even more. A pragmatic way of handling the "unknown rider" case is to find a "known rider" who was riding "close to" the unknown one. Then: - Bring up RiderDetail on the "known rider". - From RiderDetail, press *Edit...*, then *Copy Rider Times to New Number... *When prompted, enter the "unknown rider's" bib number. This duplicates the times of the "known rider" to the "unknown rider". - Edit the last duplicated time of the "unknown rider" to get a final finish time (as best as you can). Not perfect, but you get a working solution with a lot less effort. To reduce tag failures, it's a good idea to check the tags at race check-in (including using RaceDB, which supports self-serve rider check-in with tags). On Thu, Mar 2, 2023 at 6:25 PM Kim Wall ***@***.***> wrote: > A wizard that reads a GPX track recorded by a rider during the race and > attempts to determine their lap times. > > Uses the GPX course to determine the lap length and location of the > finish, interpolates the recorded track to one point per second, then > presents a filtered list of trackpoints and likely crossings of the finish > line. These can then be individually selected for import into the rider's > lap times (where they will be filtered in the usual manner). > > Intended as a backup for when there are problems with a rider's timing > tags (or the spotter loses track of their laps), but the rider was > recording the race with their GPS receiver. My tests suggest that if you > have a high resolution GPX and a reference lap time(s) to adjust the clock > offset this can get the times to within a second or two of the RFID system, > but it would still be useful to determine the lap count with far worse > precision. > > Conceivably if you had a lot of patience and trusted riders not to meddle > with their recordings you could time a small race this way (as usual, some > human input would be required to resolve close finishes), but I wouldn't > want to try to manage that at any scale. > ------------------------------ > You can view, comment on, or merge this pull request online at: > > #106 > Commit Summary > > - 3fa7dbb > <3fa7dbb> > Initial proof of concept > - 990ffd2 > <990ffd2> > Default offset based on local timezone > - efb0d7c > <efb0d7c> > Functionally complete > - 3412981 > <3412981> > Add help > - 62f19ed > <62f19ed> > Interpolation > - e43dd6c > <e43dd6c> > Update help > - 2c2d739 > <2c2d739> > Remove test filename/bib > - 8a753d1 > <8a753d1> > Tidy up prompt text > - a97c14b > <a97c14b> > Merge branch 'esitarski:master' into kimble4-importgpx > - 63d54ad > <63d54ad> > Error message if no race > - 93b6c19 > <93b6c19> > Process lap length, assorted GUI improvements > - 8a19fd0 > <8a19fd0> > Update help > - 8c7931e > <8c7931e> > Fix colouring of lap times > - d349608 > <d349608> > Merge branch 'esitarski:master' into kimble4-importgpx > > File Changes > > (6 files <https://github.com/esitarski/CrossMgr/pull/106/files>) > > - *M* GpxImport.py > <https://github.com/esitarski/CrossMgr/pull/106/files#diff-055ccb8efd9f3821baf221882f1df1493edc54d02c9224618178f98e88d93ca4> > (2) > - *M* GpxParse.py > <https://github.com/esitarski/CrossMgr/pull/106/files#diff-c0c8578fc677080bf5a365698d7f1ce390843425806dc45f4d061d5a4ecd5f9f> > (2) > - *A* GpxTimesImport.py > <https://github.com/esitarski/CrossMgr/pull/106/files#diff-41d5ff90a05b50d22700beb0c680458db4cb6de08a700849795bc03242c0ebbc> > (575) > - *M* MainWin.py > <https://github.com/esitarski/CrossMgr/pull/106/files#diff-5a5f46554ef499afef996c63f6a0022d0a7e23bfe5636bf5084cff5a35c84db4> > (28) > - *M* helptxt/Menu-DataMgmt.md > <https://github.com/esitarski/CrossMgr/pull/106/files#diff-535776536d0985d0a28ae51b0853436875fd1f857a25c34fa0cc7626bd63125d> > (12) > - *M* requirements.txt > <https://github.com/esitarski/CrossMgr/pull/106/files#diff-4d7c51b1efe9043e44439a949dfd92e5827321b34082903477fd04876edb7552> > (1) > > Patch Links: > > - https://github.com/esitarski/CrossMgr/pull/106.patch > - https://github.com/esitarski/CrossMgr/pull/106.diff > > — > Reply to this email directly, view it on GitHub > <#106>, or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AABGXKNWWUMWINCGNYGHYCDW2ET5DANCNFSM6AAAAAAVN7TUXM> > . > You are receiving this because you are subscribed to this thread.Message > ID: ***@***.***> > -- Edward Sitarski — Reply to this email directly, view it on GitHub <#106 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHLK6TSZUAPYDNFOPICVRLLW25ZL5ANCNFSM6AAAAAAVN7TUXM>. You are receiving this because you authored the thread.Message ID: ***@***.***>