Harry's GPS Suite Forum

Many tracks have multiple configurations and it would be useful to be able to treat them separately and have laps stored for each. Ideally, you would want certified track with multiple configurations and the ability to select one active configuration. So, for example, with Buttonwillow you would have four configurations:

Buttonwillow
Buttonwillow Reverse
Buttonwillow wo/Star Mazda
Buttonwillow Reverse wo/Star Mazda

When you selected Buttonwillow, you would also be asked to select a configuration. Each configuration would have its laps, best lap, reference lap, etc.

This has been a longer lasting discussion in the past. The discussion pretty much stopped when I introduced automatic track switching during track download. If you check the Tracks list, you will see many tracks with multiple configurations. Each of the configuration is defined as a full track. As soon as you load it, all other configurations for this track will have their POIs removed, making the loaded configuration the 'active' one. The track entries including lap times stay on your phone unchanged. So switching is as simple as loading a track (configuration). This solution has no real disadvantages except you need to be online to switch.

A concept with a track with several configurations would be 'cleaner', no doubt. On the other hand, I need to defer other features if I would implement that.

- Harry

Thanks for the explanation ...

LapTimer seems to be relying on the split triggers being predefined in the track registry. If I download a track and add personal split triggers and then later have to purge this to change configurations, I have lost my split triggers. My laps may be retained; however, when I switch back I likely won't get my split triggers in exactly the same place so now my old split times won't align with the new ones.

Possibly a way around this is to export a custom track for each configuration via email and then import them later as needed instead of using the general track registry. Will this work?

Two approaches to solve this: either you make your splits the official splits, or you go the route sending the .hpoil et to yourself and importing it later from Mail. To go the former path, the track set we are talking about should not have splits defined already (otherwise we break all other user's recordings / make it none comparable). In case it has no splits yet, just add them an certify the track as usual. I will replace the original then. Please add a note what exactly as been changed.

- Harry

Harry, thanks for all your quick responses. You are clearly a very dedicated guy. I just bought a Dual XGPS150A GPS and a BT-1 (for v16) so I'm definitely planning to put all your good work to use.

I use more splits than most people would want so I'll try using the export/import option and see if that works.

I think this example shows that it would be useful to allow users to store multiple, customized track configurations that they can individually activate. If there were a simple way to mark a track as 'inactive/active' this would likely be sufficient. Having to physically remove a track and all its laps to accomplish this is complicated. Perhaps an active/inactive track flag would be something that could be be included in v16

One other thing that you might want to consider is to provide a way to recompute the split times for a track configuration's laps when their track's split triggers are changed. Since the split times are currently fixed at record time, the lap split time history becomes useless if the track's splits are later changed. No other lap analysis program I have ever seen has this limitation.

Just to be on the same page. You do not need to remove tracks or laps. Once you load a new track set (either from Tracks or from a your personal mail), LT checks if a conflict occurs and askes you if it should remove the conflicting POI Set - NOT laps or tracks. It is really pretty simple.

I understand the request and agree activate / inactivate would be nice, but I simply need to dedicate my limited time to things that are requested most often. The point is on my lists and gets prioritized according to the overall situation

I had a problem with multiple POI's for the same location this weekend. I thought I had deleted the offending sets from the lap list page, but when I tried to define a new POI, HLT said that there was already one nearby. There was also a start POI listed that was hundreds of miles away. In the end, I had to pull up map view to find the offending POI's and delete them from there. It turned out that the POI's hadn't been deleted, they just had the reference line empty. Interestingly, it still recorded a run with split points at the correct location, but there were no POI's for splits listed in the lap list page, only start and finish. I went back to map view and edited the POI's there. At one point during the process after a crash, the program restarted with the message that two errors in the database had been 'corrected'. Not so much. That's when things really got ugly and the hundreds of miles away start POI appeared.