I just doublechecked your samples in the linked thread, both contain gravel roads, I guess this leads to the long ETA. However, when throwing them as gpx into Calimoto I receive this result (due to import deviation longer distances then in Kurviger, but even there no suiting ETA):
While downcalculating to the real distance of your samples with an average factor we have an ETA in Calimoto for the first route of 4:23 h and 6:20 h for the second one. This significantly deviates from your statement:
Would you mind to explain? Or did I make a mistake?
When i did search correctly, then in Italy 90km/h are allowed. In OSM is no speed tagged.
97,8 km in 1 h 19m are 74,4 km/h (I trust @Ivan).
When we could drive exact 90km/h, we would require 1h 4 min. When I add the known 20% for conservate estimation (city lights, somd slow vehicles) then I have 1h 18 min again (±1 min).
So from my point and experience no suprise.
As far as I know Calimoto is also OSM- based, so no surprise, the result is similar.
Interesting is the result from basescamp. I guess Garmin has own statistical data as Google.
What we know, also from examples of @lockheed , that the type of highway is essential. In the 9h-route, there are a lot of tracks (speed ~ walk).
The Italy-Route has mainly highway secindary/tertiary in OSM, the short one from @lockheed is highway=unclassified (some kind of highway to connect two areas, can be also within a village).
So I guess, type of highway is a biggest factor.
But nevertheless. @BorisCH used nearly 4 hours. We talking about what is less wrong?!
Another possibility could be to analyze all thd gpx we all have ridden, and some smart algorithm does the same as Garmin and Google are doing.
Best: maintain speed limits in OSM, where possible. edit: but even if maintained, there would be sign of allowed 90km/h?
Naturally. This statement is based on two factors.
For over a year, I had paid versions of both Calimoto and Kurviger and I was often riding with both On, to decide which to keep. Throughout this time my observations were that with Calimoto it was hard to arrive quicker than it estimated, with Kurviger practically always the time estimated was from ~2x to ~4x longer than the actual riding time.
(If you wonder why I chose Kurviger in the end - I liked it also allowed unpaved road routing and I also liked the feel of the company/app better).
In case of this specific route - this is a well-established circuit I designed. For Calimoto, there was a slight deviation, as it did not allow to routing through “unpaved” roads, so the actual route was maybe 1-2km longer (omitting unpaved sections), but for the 95% it was the same. When I settled on Kurviger only, I optimised the route, hence the slight difference. However, even though the Calimoto route was slightly longer, the estimate was still not far from dead-on.
But anyway, as per #1, my experience is that this difference is not limited to some peculiar routes but affect (almost?) all I rode over years. The difference is not always as massive, but it is always significant - to the point I could not rely on it in any way, e.g. when I was riding on A and B roads from Poland, through Czechia, Austria, Germany, Austria, Italy to France and I had to painfully recreate the route planned in Kurviger in Google Maps and/or Calimoto to get an idea how long each section will take to traverse.
I remember the previous topic as well. I myself am always annoyed by the deviation. I calculate for myself that I drive 60 km per hour and then I can determine from the remaining distance what time I arrive somewhere. But actually you don’t want to have to do this while driving, it’s distracting. Building in a function so that for example a driving profile or percentage can be set would be great.
Thanks for clarification, so you compared deviating route plannings. Keeping this in mind I am a bit puzzled of your statement that Kurviger is more or less out of scope regarding accuracy of ETA in comparison with competitors
However, what I see here in the discussion is that we have both cases, for some the ETA is too long for others too short - so my wish would be to enable the user a manual correction of ETA calculation.
Thanks for clarification, so you compared deviating route plannings. Keeping this in mind I am a bit puzzled of your statement that Kurviger is more or less out of scope regarding accuracy of ETA in comparison with competitors
I’m not sure I understand what you’re saying. There is a slight route deviation between Caku and Kurviger routes in this particular example, but as I mentioned, I rode tens of other routes where the routes were identical between Kurviger, Calimoto and GMaps, and the ETA was very significantly higher in Kurviger.
Plus, even if we forget the competition, when a 211km route is estimated at 9h20m for a motorcycle, then it is clear there’s a major flaw in how some types of roads/tracks are interpreted by Kurviger when calculating ETA.
Anyway, I think Toffel might be onto something with “highway” and “track” types being the main factor here.
I am not sure if the elevation is accouned for in the algorithm, but it should be. If the route goes 1200m up and 900m down on a 17km section, the average speed will be lower then on the same distance where the the elevation changes 240m up and 380m down. Having had a look at google street view, the two roads do not appear to be that much different in terms of width and road surface, whatever the OSM tags may say:
Rein auf OSM-Daten basierend, kommt m.E. durchaus eine plausible Zeit raus. Die Realität passt nicht dazu. Hier hat @BorisCH einen guten Punkt angesprochen. Neben den reinen “Stammdaten aus OSM” ist ja auch der Strassenverlauf bekannt!
Wenn man (man - weil ich das nicht kann) programmtechnisch ein virtuelles Motorrad baut. Gewicht, Reibungskoeffizient, realistische Beschleunigungswerte. Das lässt man über die Straße fahren. Kurvendurchmesser, maximale Kurvengeschwindigkeit, dann bekannte Werte aus OSM kombinieren, wie innerorts, außerhalb Ortschaft, maxspeed, Oberflächenbeschaffenheit. Ggf. noch aktuelle gps-Daten oder gpx-Aufzeichnungen .. ui..ui.
Das wäre doch ein Ansatz?
Als Nebeneffekt könnte Kurviger die Schräglage vorhersagen.
Yes, many thanks.Please invest and fix those bugs.
This mornig I tested with Googlemap (by setting the start date in July) this track,between the points 24 & 25, and Googlemap gave me the time of 3h35’
If those errors will not fixed soon I have to change system; the choice will be MyRoute or Calimoto. In Month August I’ll do another trip of approx 1500 km in the French Montains and I cannot accept such time errors (1h20’ Kurviger vs 3h35’ Googlemap)
Good luck - then you may try to fix those bugs in their forums as well. MyRoute counts the same 1:19 for this segment, and Calimoto is slightly “better” with 1:34.
BaseCamp and GoogleMaps I picked from this thread, the others are testet on the corresponding websites.
Because in the discussed route segment are only few cities to drive through (except San Remo) the time of 01:19 is challenging but achievable. An average speed of 40 or even lower is ridiculous.
I counted 13 WP along the coast. IMHO, that is not much at all given that you want a very specific route. I know saying “along the coast” is very easy, but setting 13 WP on the desired road is also neither difficult nor it takes much time…
Hehe, in the case of following the coast, in Italy in August you can belive in GoogleMaps. Below 30 km/h is realistic because of the behavier of the idiots around you. But Google have statistik about Millions of measurements of all phones. All other calculate like the streets they found. They do not collect your data from every phone. This should be known. Or not ?
Well… Many people do actualy track their rides and store them in cloud… but there is no benefit from this “uncollected” data to improve the ETA algorithms… for the sake of saying “we are not collecting your data”. Can I donate some of my data to Kurviger for a good cause?
An interesting idea. I gave it some thought and as a result I must disagree. I do not see how a change in elevation would consistently translate into a change in speed that could be reliably factored in ETA estimation. Most of the time, I think, there’s no influence, and when there is, it could go both ways (faster or slower).
I think the simplest quick fix/win (at least to address the gross overestimation of ETAs) would be for the app to just assume a unified speed of 50-60km/h across the board for ALL roads and tracks on which OSM speed limit is not specified. With that, I am pretty sure we would get in the ballpark of realistic ETA. Once there, we could try to perfect it further WHILE having a good-enough ETA already working.
Also, implementing some Machine Learning (AI) based on routes tracked by Kurviger (as others mentioned) would also be a an amazing thing. I.e. once a section of the road is traversed by any user, Kurviger updates its speed estimate factoring in real world data.
Well, I would argue, that the higher the gradient is, the more hairpin curves you will have. The more hairpins - the more you brake and accelerate, reducing your overall average speed. But that is just an hypothesis, which can be verified by evaluating data.
This is something I thought about too. Before you slip into 25-30km/h avrage range on asphalted roads (for hours of riding) without having reliable data - just apply 50km/h flat rate.
