Op vr 6 mrt. 2020 om 01:41 schreef 'Arndt' via OsmAnd < [email protected]>:
> > > On Thursday, March 5, 2020 at 5:44:36 PM UTC+1, Harry van der Wolf wrote: >> >> >> The issue is OsmAnd and its heuristic coefficient of 1.0. Not any other >> application is doing that. >> >> > Hi Harry, > > it's not that easy. BRouter is operating at heuristic coefficient = 1.0. > Going heuristic is "unconditional surrender" and leads to artefacts that > can be easily detected. > > I think what mapactor, waze and the like are doing are "hierachical > constraints",which is about as bad, but not so easy to detect. > > For BRouter I worked on 2 aspects: > > - the raw "node crunching power", which is about 1 Million nodes/seconds > on a server-processor-core, or 100k/second on a smartphone. This is just > engeneering and tuning. You cannot compare the osmand-router with BRouter > here: BRouter is working on specilized data files which are 8% in size of > usual OSM data and contain the street network only, while OSMAND data are > 170% of usual OSM data size. > > - the other aspect is the "averge cost factor", so the ratio of average > versus minimal cost, which should be close to 1 and is e.g. about 1.05 for > the "car eco" profile, 1.16 for "car fast". It's important to be close to 1 > here to keep the search area small. > > regards, Arndt > > > I know there is a lot more behind the shortest path algorithms then only the heuristic coefficient. And indeed Mapfactor is using hierarchical constraints (I don't know about the others). And yes: file size does matter but that's < 10%. (And it also matters for screen rendering. I use OsmAnds "roads-only" maps for car navigation on my Android car head unit which give 30%-300% better rendering performance as well.) I also know that an hc=1.0 "theoretically" always leads to the fastest (sometimes shortest) route. Like mentioned: already since 2011 when OsmAnd switched from 1.5 to 1.0, I do these tests: so actually about 9 years now (like you are doing as well for Brouter, I suppose). But the 100% theoretical "hc=1.0" route is on long distances over 150 km very often (>98%) exactly the same as the "hc=1.3~1.5" route. For OsmAnd car (!) navigation I have tested with many hc values. I don't believe at all in "unconditional surrender" when going away from 1.0. (And obviously neither do all those other navigation app builders.) It all depends on the number of paths you can choose and speed difference they force on you (which is completely different for walking or cycling where the average speed is fairly constant, unless there are big elevation differences) For cycling and hiking I always just use an hc=1.0. Simply because the distances are very often below < 50 km. For car navigation in a big city with lots of possibilities and OsmAnds use of penalties for traffic lights and speed reducing measures, it is indeed important to stay close to 1.0. (driving thorugh Den Haag (quite often) or Rotterdam, an hc<=1.2 does give better results, than an hc=1.5. I immediately admit) When driving > 150 km, it is most probably some 3~8 km in town in the beginning and the end, and the rest over motorways/highways. At that moment an hc >= 1.3 and <= 1.5 works really excellent and almost always gives the exact same route as an hc=1.0 What's more: I did see that Osmand had artefacts when using 1.0 on longer routes (when I had the patience to wait 8+ minutes for the calculation to finish). It calculated routes with longer travel times and travle distance compared to using an hc of 1.3~1.5. And other apps calculated the exact same route as my 1.3~1.5 did. Obviously because they also use a different hc, but the OsmAnd hc=1.0 route was longer and taking longer. As such I don't care whether that is a bug or not, or a memory issue (although I did file an issue for that some years ago and so did other users): The 100% theoretical calculation was simply not correct! Again: Using the exact same OsmAnd with 1.0 and 1.3~1.5 routing profile. And with 1.5 for example, the route might not be 100% perfect, but it is nearly perfect. If I have to drive 800 km, and in the last 3 kilometers the 1.0 takes 2 other city roads, thereby being 10 seconds faster, I don't care at all. If I have one "wrong" red traffic light, this time reduction is already gone. Especially when having some traffic jam completely ruining this 10 seconds time reduction of an journey of 8+ hours. There are so many real world parameters influencing your real travel time. Slow trucks which on a busy day reduce your average speed drastically, a 5 minutes shorter/longer resting period after 2~3 hours drive, a calm or or very busy petrol station along the route, etcetera, etcetera. And when there is some deviation (or you just took the wrong exit or street in a city), the 1.3~1.5 almost instantly gives you a new route. OsmAnd with 1.0 does not and is painfully slow at times. Again: Speaking for car (!) navigation, the hc=1.0 "approach" is from my point of view for the theorists who want to be 100% theoretically correct. It is not an approach 95% (or so) of all other navigation apps programmers/companies choose having experience with what the real world does to your 100% theoretical route. (and sorry: I really don't want to offend you for using 1.0 in BRouter. I have used it quite long for cycling and I think it is excellent.) So in short: - I live in the Netherlands and do quite some cycling. With the dense cycle network in the Netherlands I do use the standard hc=1.0, but distances are always below 50 km (I'm a lazy cyclist) - For driving in a big city, I use an hc=1.2 - For driving outside the city and everyday use, I almost always use hc=1.5 best regards, Harry -- You received this message because you are subscribed to the Google Groups "OsmAnd" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/osmand/CAGARPpsQdsUQq%3DhCmQZYZzc8sfjzbM9C4NKXRoFXemw-jcWhVA%40mail.gmail.com.
