Poutnik Fornntp <poutnik4n...@gmail.com> writes: > It may be a problem, if there is a bug in the algorithm. Or, it may be > the result of different algorithm priorities, comparing OSM routing > and OsmAnd routing. Or, difference between algorithm and human > priorities.
Agreeing and saying part of this a little louder: Talking about what the right answer is for routing is very difficult. Given a map database there are issues: what are the assumptions about travel time vs road speed what are the assumptions about turns, stop signs, lights what is the goal? shortest time, shortest distance, a blend, "eco routing"? Besides an estimate of the time and the distance, are there or should there be "penalties" applied that express the human concept of "taking this left turn is scary, so I would rather have a 43m route that does not include that left turn than a 40m route that does". Generally, for something like osmand, it is considered to be doing well if the calculated route is reasonable, relative to someone who does not know the area. That's different from the best route with local expert knowledge, but it's great for a non-local compared to being lost. The advice to use other routing engines is also excellent. Besides brouter, there are multiple engines available for foot, bicycle and car. https://www.openstreetmap.org/directions?engine=graphhopper_car&route=-38.1530%2C176.2230%3B-38.6609%2C175.9215 Mark Howard writes: > Via Oruanui Rd is 3 kms shorter and 4 minutes quicker. Do you mean that it is *actually* shorter and quicker, on average, if you drive each way 5 times and record the data? You are talking about a route that ORSM and graphhopper both come out as: 82km 1:07 82km 0:56 but they seem to pick the same route. If osmand chooses a route which is 3km and 4 minutes longer *in actuality* than some route that another engine finds, that's really not so bad. Digging into this is likely going to be some combination of checking the representation in OSM of the roads chosen and not chosen to be sure they are accurate. (Proably you know this, but *do not* adjust OSM to have data that is not accurate to make routing come out better.) looking at the routing code to see what assumptions it makes about turns, lights, and so on computing two routes, one to an intermediate point you like and then from there (just route to intermedidate, then again, and choose "add as subsequent destination). If the total route as displayed is shorter/faster than the original route, you have found a route computation suboptimality. and steps on the path to really addressing this are: setting up osmand's router to meet the same interface as the OSM web page modifying osmand on android to export computed routes in the same format writing some code to compare routes, and to make the various routers evaluted the other routers' choices surely some more hard work after thtat Looking more at your particular routes, I wonder if there is something in the OSM data that one engine interprets very differently. You can also help make progress by calculating shorter routes, basically starting a bit before the divergence. Look at this route: https://www.openstreetmap.org/directions?engine=fossgis_osrm_car&route=-38.3476%2C176.0065%3B-38.6370%2C175.9212 then move the red marker SW just barely. The two paths are both 44km 0:34. If I move to Kinloch Road, it's 43k 0:33 for one, and presumably 45km 0:35 for the other. So basically I am concluding the difference in OsmAnd and osrm's opinions about the total cost of one of these routes is on the order of 2km 2 minutes. Until you drive both and actually find out what happens (maybe you have and that's what you mean), it's hard to say this is wrong for sure. -- 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 osmand+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/osmand/rmift50rnk8.fsf%40s1.lexort.com.
signature.asc
Description: PGP signature
