I'm pondering to create a small tool for "forging" GPS "tracks" (with timestamps) from mere GPS "routes" (no timing info).

The reason for this is that I prefer to go easy my cellphone's battery on longer rides, but it would still be nice if I could post those rides in Strava, to keep a log of activity, including the maps.

So the plan is to approximate the speed by just using the total duration of the ride. The thing is, I need to accommodate for climbing segments. A 100k ride with 25kph average, even up the 10% slopes would net lots of illicit KOMs.

To get a feeling for this, please share your experience how climbing and descending time relates. Let's take a 10k climb with 500m vertical gain, and ride it in an hour up and down, how would you split the hour between climb and descent? Along the lines of 45min up, 15 down?

_________________
Bikes: Raceur, Beateur

Put your phone in airplane mode, battery problem solved.

Because you are planning to create fake data, I'd suggest not to try to make it look legit.

So use constant 4kph everywhere.

Seriously how are you having battery issues assuming modern smart phone? My htc evo 4g lte in airplane mode had more than half battery after a 9 hour ride.

Haha, I had no idea GPS would still work in airplane mode. Cheers fellas, guess that solves it.

_________________
Bikes: Raceur, Beateur

This would be interesting from a route planning perspective.

For walking the Naismith formula is commonly used, which is 5kph on flat or downhill, plus 10 minutes per 100m height gain. I guess you could work out your own formula for cycling if you reviewed some rides.

Fish, hmm, maybe. But the problem is that cycling is a bit more dynamic in that downhill sections are much faster, and there can be wind, etc.

Anyway I thought about a possible algorithm yesterday while riding, and it goes along those lines:

1 - you have total time, distance, and vertical covered
2 - split the distance in half, and calculate how much vertical is covered in each part
3 - split the total time, weighed by how much vertical is covered per part
4 - you now have (estimated) time, distance, and vertical covered per section, start over drilling down per part

There are of course corner cases to be worked out, e.g. how to weigh descend-only sections against climbs, but it's a start. What I like about this approach is that it doesn't use any rule-of-thumb input, but calculates solely based on the available data.

And the best thing is, it would be easy to inject "savepoints", e.g. if you take the time at the bottom of a climb, and on top, you could use those section times to get a fairly accurate output.

_________________
Bikes: Raceur, Beateur

LOL just assume there's a net downhill, and everyone knows you can descend at 60+ kph...so Put down 50 kph to account for uphill and you'll be fine.

_________________
I only train on days that end with "y".

Eli