Only valid for active forum users. Active means at least 30 postings within the last 30 days (no spam postings). This will automatically being checked at www.starbike.com shopping basket so make sure that you are logged in at the WW board!If there does not appear a WW discount position when you check out you do not have enough postings!

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?

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 covered2 - split the distance in half, and calculate how much vertical is covered in each part3 - split the total time, weighed by how much vertical is covered per part4 - 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.