My algorithm isn't tested yet, but here's what I have in mind, slightly simplified:
- Find all segments where the speed is no less than some threshold for driving, for example 14 m/sec. This step is for computational efficiency only, to assist with the following step.
- Using this list of "fast" segments, find segments in which the Garmin reported progress at least some threshold distance ahead of the threshold for driving. For example, the make a list of all segments where the distance covered was at least 500 meters greater than the distance which would be covered @ 14 mps for the same time period. These segments may include points which are less than the speed threshold, and will exclude some points which exceed the speed threshold, since bicycles are capable of going fast when descending, but are generally unable to go sufficiently faster than 14 mps to get 500 meters ahead of that pace.
- Using these "motorized segments" as a start, extend them to points in which progress was sufficiently small to allow for a bike to be loaded onto a bike or train, or to the start or end of the data, or to points where enough data are missing to have allowed for a bike to be loaded or unloaded while the Garmin wasn't recording.
Hopefully this sort of thing will go a long way towards me avoiding the mistake of grabbing Strava segments due to forgetting to shut off my Edge 500 when I'm on the road or rail.