Closed gerhard-tinned closed 2 years ago
Lee-Carre
commented
2 years ago … the route leads […] and exiting trough the tunnel walls — there is no exit. In short, it is impossible to follow that route!
Part of the problem sounds like inaccurate map data, which should be fixed first.
Though, that detour route is amusing; quite the long way around(!) 😄
Lee-Carre
commented
2 years ago Startpoint: Schlachthammerstrasse 97, 1220 Wien Endpoint: Stadlauer Straße 41A/Hof 4, 1220 Wien
It took quite a while to find these on the (Web) map. Nominatim wasn't able to resolve the destination string.
In future, supplying coördinates or (better) a link would be far less ambiguous (perhaps the report template needs to be updated).
In the course of my digging, I yielded the original route (matching the OP). However, when changing the destination only slightly (by a couple metres) (and changing nothing else) the optimal route was yielded.
So, how exactly was that destination given to OsmAnd?
Lee-Carre
commented
2 years ago Is there any way to […] use a different routing engine?
Yes; in the profile configuration, under navigation type, you can use a Web-based API (of your choosing) for supplying routes. This, of course, requires that you have some kind of Internet connectivity (at the time the route is requested, at least).
You may also select Brouter for use, if you have it installed.
Though, given my earlier comments, the assumption that the routing algorithm is faulty, and that a different one will yield better results, is demonstrably false. Especially when, as you say, the map data isn't accurate.
gerhard-tinned
commented
2 years ago I am sorry. Did not know that. On the other hand my previous experience is that is gets closed without any attempt to fix it anyway so ... well, I hope this time is different.
It does not help to change the destination by a few meters when the destination was selected by the address provided.
I also think it should calculate the correct route even if the destination is a perfectly valid address (of a business by the way).
The Destination was provided as I copy-pasted it "Stadlauer Straße 41A/Hof 4, 1220 Wien" which is the official address of the "Werksalon Co-Making Space GmbH".
gerhard-tinned
commented
2 years ago Especially when, as you say, the map data isn't accurate.
Can you elaborate on this? What is wrong in the map data? And why do other openstreetmap navigation tools still manage to route correctly if the map data is bad? Would be interesting to understand it by getting more details. Thanks
Lee-Carre
commented
2 years ago […] my previous experience is that is gets closed without any attempt to fix it anyway so … well, I hope this time is different.
Which is why quality, thorough problem-reports make a difference. Firstly by checking that it is actually a problem with (in this case) OsmAnd.
Tickets can be reopened. So, opening a duplicate, instead of commenting in the original, is spammy. It contributes to maintainers being more hasty in closing dubious tickets.
While ideally tickets wouldn't be hastily closed, developers are busy, and the more time spent doing triage on tickets is less time for actual development.
There are frequent reports complaining about bad routing in OsmAnd, which often turn out to be a result of inaccurate map data. Software isn't magic; garbage in, garbage out.
Besides, even if the map data were (somehow) perfect, routing is imperfect. Graph Theory is far from a solved problem in mathematics, let alone computer science. Perfection is difficult (read: practically impossible) to obtain, especially in every situation (including weird edge cases). Frankly, given that OSM (& arguably digital mapping) is still in its infancy, I'm often impressed that it does so well in most cases. But, then, I have technical insight into some of the challenges.
To elicit a desirable outcome, focus on helping the developers (or, since I notice you have experience with software development, contribute some PRs). If a user sounds like they're whining, amid complaining, then that tends to not be received well. Imagine being on the receiving end of that, every day.
It does not help to change the destination by a few meters when the destination was selected by the address provided.
That entirely misses the point, and falls foul of what I had just advised against.
You seem to expect software to be flawless.
Simple example, for name-to-coördinates resolution problems; if the user inputs a city name (because they're travelling from another city), where precisely should the resolver place the marker? A city is a large area.
Just use the computed centroid? Well, what if the user doesn't want to go to the city-centre, but only the suburbs? He'll complain about bad routing.
Well, place it at the (nearest) outskirts, then? And what about the user who wants to go to the other side of the city? He'll complain about bad routing.
Seeing the pattern?
Or, in a different context; when a camera detects that the scene is too dark, should the auto-mode fire the flash (if allowed to) or increase the exposure-time, or increase the sensitivity, or open the aperture? How should it determine the trade-offs between each of those? Much of it comes down to the intentions of the photographer. Last I checked, software can't read the minds of users. So, if it has to make a decision (because it's not allowed to ask the user), then it'll have to make a guess, which is liable to be wrong.
I notice that you've contributed to a multimeter repo; imagine a user complaining that his multimeter didn't select the correct measurement mode for him (let alone the correct range). Well, how's the meter supposed to know?
OsmAnd did as it was told to; find a viable route to the coördinates which it was supplied with. If you're unhappy about the coördinates supplied by the address-resolver, well, that's a different problem. See my earlier remarks about the problems of address-to-coördinates resolution.
Another factor which comes to mind is that smaller access roads might be missing near the destination. Else, you expected the car profile to navigate a pedestrian area. Instead, set the carpark as the destination, since the remainder will be on foot.
Notice that, at the end, OsmAnd draws a straight line from the nearest road to the destination point. So, it's making a best judgement from ambiguous input.
[…] it should calculate the correct route even if the destination is a perfectly valid address (of a business by the way).
That's not how it works. Software needs coördinates. Thus, for human-readable input it relies on some kind of scheme to map from address to coördinates. Compare DNS; how would a host connect if it can't resolve the hostname to a numerical address?
How would software know what address is ‘perfectly valid’ or not? To software, human addresses are just text strings. Even to humans, textual addresses are ambiguous & messy. I often send people a geo: URI with coördinates (e.g. in messages), instead of a description, address, directions, or whatever. A URI is much more succinct, and unambiguous. If they want to navigate there, it's easy for them to pass the data to their favourite app. I've even considered doing this when placing food delivery orders, since the drivers are all using phones to handle orders & navigation, anyway.
Compare developers communicating with code snippets, for clarity instead of natural language descriptions, or in OSM we often refer to features by mentioning the relevant tagging (amenity=parking or whatever). Same idea.
Complaining that it should just auto-magically work anyway doesn't help. It ignores the problem (while demanding that someone else fix it).
The Destination was provided as I copy-pasted it "Stadlauer Straße 41A/Hof 4, 1220 Wien" which is the official address of the "Werksalon Co-Making Space GmbH".
Where was this pasted? Into OsmAnd's search?
‘Official address’ is meaningless to software in this context.
Sounds like this maker-space needs to work on improving their OSM presence. For example
geo URI or (possibly better) a GPX, or relevant link to OSM, so that people only have to click that, choose their favourite app, and start driving.Lee-Carre
commented
2 years ago Especially when, as you say, the map data isn't accurate.
Can you elaborate on this? […] Would be interesting to understand it by getting more details. Thanks
If you want a deep understanding, then start reading more about OSM (such as on the wiki). You're asking for a university lecture series of explanation, otherwise. GH tickets aren't the place for such things.
However, since you're persistent, I'll try to address the basics.
What is wrong in the map data?
You described it, yourself(!): “Additionally, the route leads literaly onto the highway and exiting trough the tunnel walls - there is no exit. In short, it is impossible to follow that route!!!” 🤦♂️
Think of OSM data like a software dependency; a bug in the dependency isn't the fault of the app using that library. Having a rant about the app, and casting blame, doesn't help.
How can you help? Ensure that the map data is accurate. Since you're local to the area, go do some surveying. Everything you need to learn how is on OSM. RTFM 😉.
why do other openstreetmap navigation tools still manage to route correctly if the map data is bad?
Define ‘correctly’. Different users want different routes (even in the same mode / vehicle; shortest, least-time, most efficient; those last two depend on many more factors, like road quality, congestion, traffic lights, crossings, …)
To my understanding, route-finding is an application of Graph Theory, which is often heuristic rather than deterministic (what if two paths are equal (by whatever metrics you're judging them)?).
Another contextual answer is Postel's Law.
Inaccurate data is only relevant if trying to route through that area. A route will likely be found, but it is liable to be sub-optimal.
A route which doesn't take the tunnel with the phantom exit, won't be affected by that phantom exit.
How do you define ‘bad data’? That's your term, not mine.
Data being inaccurate may simply be because meat-space changed, and the map hasn't yet been updated. So, it may have been accurate in the past, but not since the change. Again, you can help by contributing.
Different implementations do things differently. They're designed for different cases & users. Much like an F1 car versus a cargo truck.
To start, you would do well to cite which other app you used. You didn't mention the name of it.
Next, you would need to ensure that we're comparing like for like. Was it using exactly the same coördinates (not human address(!)) for the origin & destination of the route?
Which algorithm is it using? How is it configured & tuned (maybe it's finding the shortest, rather than the fastest or most efficient)?
Lots of variables, which makes giving an answer (other than ‘it depends’) quite difficult.
Lee-Carre
commented
2 years ago Else, you expected the car profile to navigate a pedestrian area. Instead, set the carpark as the destination, since the remainder will be on foot.
Having examined the map around the destination a little more closely, I noticed a couple carparks to the south-east. Setting either as the destination yields an efficient route (consistently, with either OSRM or GraphHopper).
I also now see what is really meant by the glib / flippant / facetious remarks about being expected to exit a tunnel through a wall where no exit exists.
More interestingly & constructively, when using the same end-points that yield the objectionable route, but selecting GraphHopper as the algorithm, it suggests a radically different route entirely. This suggests that the algorithms are having to guess (and each guesses differently).
Likely because they're being asked to do something invalid; find a route to drive up to the door of the building (in what I would assume, from various clues, is a pedestrian area).
Why the difference (for our budding student)? Well, because you're telling the algorithm to traverse a different part of the graph. So, yeah, the result will be different. Especially when there are no edges for it to traverse near the destination. So, it found the nearest vertex.
Would you prefer that, instead, it give up and tell you that no possible route exists? How would that help? People would just complain about that, instead.
It tried, but you're not happy with that either. 🤯
So, to address your original question:
Is there any way to fix that broken route calculation[…]?
Yes; better results require:
access key) along with duration and other characteristics / properties; marking footpaths within the pedestrian areaI'm now starting to see why #13356 was closed. It's not a problem with OsmAnd, itself. 🙄
Smarter use of OsmAnd includes
I'm reminded of an old quote
“On two occasions, I have been asked [by members of Parliament], ‘Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?’ I am not able to rightly apprehend the kind of confusion of ideas that could provoke such a question.” — Charles Babbage (1791-1871)
Plus:
Developers can't fix PEBKAC errors. 🤷♂️
pebogufi
commented
2 years ago THANKS A LOT to @Lee-Carre for this very detailed explanations !!!
Lee-Carre
commented
2 years ago you expected the car profile to navigate a pedestrian area
Is there any way to fix that broken route calculation[…]?
After having slept, I had a different idea. I requested a route using the same destination as originally, but selecting an on-foot profile; it yielded a route much closer to what the OP demands 😄🤦♂️.
Further, the route from nearby parking to final destination (on-foot) is sensible (given limited map data).
Personally, I feel that this is a demonstration of an approach which I take. I use OSM exclusively; besides for reasons of principle (tech-freedom, autonomy, etc.), in order to ‘eat your own dog food’. That is, using OSM habitually (e.g. daily), I'm much more likely to notice when something is lacking, such as inaccurate map data (causing questionable routing, such as a pedestrian area / square which lacked area=yes causing the algorithm to direct me around the edge, rather than straight through). I make a habit of starting navigation in OsmAnd, even for familiar routes, as a sort of surveying test (as well as various features of my device & the app; an end-to-end test of outcomes). It's resulted in me noticing all sorts of data deficiencies which I was unlikely to uncover otherwise.
I cannot recall an instance in which an improvement of map data didn't resolve any dubious routing.
I've often added pedestrian shortcuts, due to the calculated route seeming a bit too long for my liking. Some shortcuts I already knew, but some I discovered by going in search of them (‘I'm sure there must be a shorter path, I wonder if it's down here …’).
This entire ticket, to me, screams of the map data needing more attention. Especially at the destination. When a landuse=commercial is given a business-sounding name (Easy Storage), yet there are no buildings; seems likely that the map is incomplete.
For example, I assume that there's some kind of barrier around the northern side of the site; is that properly mapped (so that a router might know to not cross there)? Thus, entering from the south is the only possibility.
Lee-Carre
commented
2 years ago An illustrative example of how map data can significantly affect routing, since I feel that it may help solidify several abstract concepts described earlier (and I seem to have attracted an appreciative audience of my surgical analysis & rants 😉).
I like visiting the library when I'm able. My route toward it approached from the West. The building is part of a row (block?) of buildings which run North—South, with different roads on each side. The only (public) entrance (& entrance=main) is on the Eastern side (Halkett Place). None on the Western side (Don Street). To walk between the East & West sides requires going around the block of other buildings; a several minute walk.
At the time, no entrances had been mapped; just the building's outline (from aerial imagery).
The effect was that, when approaching from the West, I would be routed to the back of the building (Don Street), since that was nearest. If the building stood alone (detached), then no problem; just walk around the perimeter to the (eastern) front. However, there are many other adjacent buildings, so the path involves several other roads. So, being routed to the back of the building, even if it's the nearest part, incurs some penalty.
The easy remedy, at the time, was to set my destination to the eastern side (where the entrance is). However, this wasn't as convenient as merely selecting the library from a list of results from querying for amenity=library (a feature of OsmAnd which I rather like). Note that it is the building itself which is tagged as a library (since it occupies the entire building), rather than a PoI node (which could be moved closer to the entrance, as a workaround).
Now, my point is that I didn't immediately assume that OsmAnd was broken and come to GH to bitch about it & whine at weary developers. I suspected that the map data didn't include the information necessary to route me to the entrance. Even if that weren't the case (or wouldn't help), it's the obvious place to start.
By that point, I'd already learned about entrance=* and encountered a few examples (including having noticed how they affected routing).
So, I added the entrance=main to the building, in hopes that doing so would help the router.
After OsmAnd had had chance to fetch the update, and I was next heading to the library (again, from the West), I was delighted to see that, despite selecting the library (building) (rather than precisely placing the destination marker, or selecting the entrance node itself), I was instead being routed around to the front (Eastern side), avoiding the back entirely. No extra walking, or having to use manual workarounds. Wonderful. Just as it should be.
It's worked well ever since. The magic of a dataset (of sound schema design) which is used to both render tiles and form the graph for routing algorithms to traverse (hence the advice of ensuring that ways (edges) which meet at a junction all share the same node (vertex)), combined with Internet distribution of data (with OsmAnd's Live Updates enabled, I've received patches within 30 minutes, before) … 🥳. This isn't your grandfather's map(!)
When doing detailed (as time & opportunity permit) surveying of buildings, I make a point of adding the entrances (and whatever else) in order to help routing algorithms to determine the right path.
Besides benefitting me, it also benefits everyone else (now and in future), including the likes of tourists & visitors who are unfamiliar.
Contrast that against merely complaining about imperfect results regardless of any other factors. Nothing would have improved, then.
This, all from ‘eating my own dog food’ which caused me to notice the problem, and prompt me to fix it.
Notice, too, that OsmAnd itself didn't change; it merely received more information. The routing algorithm was already capable of doing the right thing. The problem was lacking map data.
For the sake of thoroughness; if adding the entrance (correctly) failed to yield better results, and I'd exhausted all other ideas, then yes I would've considered opening a ticket to report the matter. Especially if several other (public; it's no good citing an example which isn't available for inspection (of its code)) algorithms were yielding desirable results. That was never the case, though, just as I had predicted from the beginning of noticing the problem.
gerhard-tinned
commented
2 years ago Thanks for your reply and the explanation. I would love to go through all of your statements but I do not waste anyone's time. I will try to focus on what I think is the most important points. I will also try to keep personal feelings out as much as possible - lets stick to the facts and the topic without getting personal.
You stated multiple times that the address is just a string and has no meaning for the software. I do agree on that. I do not agree however that you use it as an excuse. I do contribute to openstreetmaps. Maybe not in the depth like you might, but enough to understand that each address marker (the text you are talking about) is linked to an exact coordinate position on the map. So, by using the name as, lets say an alias, you get the same coordinates as well. To be exact the "Werksalon Co-Making Space" was added 31 Jan 2021 and is (according to the openstreetmap) linked to the coordinates "Location: 48.2329692, 16.4560617". Again, I agree the name is a human readable lable but I have to disagree that it is not linked to coordinates.
You defend the routing as it chooses the closest point. Well, I am not sure if that is a rule in all countries (still I assume it is) but in Austria it is not allowed to Park on a motorway and definitely not in a motorway tunnel. And yes, it is marked as a "Motorway" as well as a structure "Tunnel". And that are properties that should be readable by the software without any problems.
As Openstreetmaps also contains structures for pedestrians, it is not clear how the tunnel could be left in the way routed. Then there is the detail of 3 or 4 Trail Tracks without a marking for a place to cross. Not to mention that the motorway is below ground (also stated in the openstreetmap properties). I am not trying to make fun of it, I ust want to state the details that are in the map. I know routing is hard, but in this case, I would call this end point for the route simply wrong - which could be improved. As this route is repeatable wrong, I thought it would be a good test while improving the routing engine.
To what I would have expected to see and why:
Based on my understanding of the structures in OpenStreetmaps, the closest public accessible street for the given address (and its linked coordinates) is the Street Stadtlauerstrasse or the Dr.-Otto-Neurath-Gasse (both would be absolutely acceptable). The motorway is not the closest as it is contained/isolated in a tunnel which can not be left at a point even close enough to the destination.
Based on that, I do see that there is a service road through the "Wirtschaftshof Stadlau" (the lable asigned to the area the destination is in). Which is not a public accessible road. This street is not used for routing and that is from what I understand correct. But I see no indication that would make me think there is any problem with the map data. The motorway is declared as motorway, tunnel, underground. The streets Stadtlauer Strasse and Dr.-Otto-Neurath-Gasse are public roads (no indication of private access in OSM) ... ... This is the reason I asked for details about what in the OSM data is wrong, incorrect or however you want to call it. (I am not hung up on wording here) It is not that I believe the map is perfect, I agree it is impossible, I just do not see the issues in the map data you see and I want to understand it - Understanding an issue means understand how to fix it, fixing it will improve OSM data and makes the experience better for everyone. Isn't that what we all want??
The duplicate / spammy ticket behaviour. I did not open a second ticket to spam. I opened it because the problem is, at least from my perspective different. Yes, there is a ridiculous detour, and yes, I have that 90% of the time I try to calculate a route but that is the case for the other issue. This issue is more about the, well lets call it for a second "Park in a motorway tunnel and jump head first through the tunnel wall" issue. I am not sooo deep into OSM and routing to be sure if those are the same issue or not, but at least to me they seemed different but related. And if am not mistaken I stated it is partly related (the detour part is the part) linked to the other case.
If it is the same issue, please tell me and I will try to keep it in mind next time. In that case I am sorry to create a duplicate.
Your suggestions and my thoughts
You mentioned change the destination a few meters / choose a carparek close by / .... I agree, choosing a different destination can change the route that is deemed best. But The complete area called "Wirtschaftshof Stadtlau" basically has only two street leading to it. The "Stadtlauer Strasse" and "Dr.-Otto-Neurath-Gasse" based on that, I would basically expect the destination for the car (and the continue on foot) to be anywhere on those streets. If you move the destination slightly inside that hole area, only the end spot on those streets should change. (at least as long as a car profile is used for routing)
In one of your later posts in the ticket I saw those points ...
Yes; better results require:
* giving OsmAnd valid input (setting destination to somewhere it can reach, such as the nearby parking) * sanity-checking the results, rather than blindly following them on the assumption that everything is magically perfect * [improving the map](//www.openstreetmap.org/welcome), so that it has more & accurate information to find optimal routes — for example, it appears that some of the carparks don't have connecting ways; checking signage for who's allowed to park there (and setting a suitable value for the `access` key) along with duration and other characteristics / properties; marking footpaths within the pedestrian area
First, I am contributing to OSM. Maybe not yet in the depth and details as you might, but I try to do my best to improve the map where I can and how I can. But that is not the pioint isn't it.
On the other hand, a "valid input" is a location on the map, isn't it? That would be a name like the "Werksalon Co-Making Space" or an Address like "Stadlauer Strasse 41A, Hof 4, 1220 Wien" No matter what human lable is used, it is mapped to a coordinate location 48.2329692, 16.4560617 on the map. I like to understand it but I do not understand why this is not considered a valid input. When entered the name or the address Osmand finds it and points to the exact coordinate location on the map. Wouldn't that be the indication for a valid input??
For the sanity check, It is easy to check the result if you know the area or more like the area of the entire route. On the other hand, if you know the area and the streets, why would you use a routing app? You would know it anyway and not use it. Maybe you would use it to find the best route? Well, in my experience Osmand does not show a good route - but that is more a topic for the other ticket. My experience is to use a routing / navigation app to find the best route or if you do not know the area. Sanity check is down to a minimum like "am I allowed to drive there?" and that sort of thing.
I'm now starting to see why #13356 was closed. It's not a problem with OsmAnd, itself. 🙄
Smarter use of OsmAnd includes
* setting the carpark as an intermediate destination, and the entrance door as final, since you'll have to change mode of transport anyway * for auto-switching profiles (from driving to walking), use the route planner with destinations like above, and select by-car for the first leg, and walking for the last * if you want to follow an exact route of your choosing, then either use the route planner to specify one (and save the GPX) or record a track while driving your preferred route. Then, in either case, when you next want to navigate the route, tell it to follow your planned / recorded path. You can then micro-manage the details to your heart's content 😄 * you could try experimenting with setting various (types of) highways as to-be-avoided, to influence the route-finder * as always, use the route-recalculation feature; deviate from the suggested route, where you deem best, and another route will be suggested
I agree, the mode of transport must be changed, but that is always the case as it is not very likely that you can drive with a car directly into the building (with very few exceptions). But I think it is a bit much to expect the user to inspect the destination area, find the closest parking area, and start adding those into the routing. I would argue that most users would expect the navigation software (in this case Osmand) to stop the navigation for a car at the closest public accessible road element and continue from there a walking route. And I have seen this approach a lot of times. Most often is the route with a different mode of transport coloured differently to indicate it. Other times the routing just ends at the nearest by car public accessible point. Both are acceptable ways and based on the route suggested, Osmand is trying to do the same (the way from the motorway to the destination). It is just the wrong spot to divert from the street.
Avoiding highways would work in that scenario but would not always result in an acceptable route. The recalculation feature also requires that you know the the area and the correct route (also part of the other ticket) which would make the use of a navigation app less useful. (my opinion)
I try to keep my emotions out of it and stick to the facts. But still I get the feeling, instead of admitting that something is wrong in the way the route is calculated (I am still only referring to the fact that it exits the motorway through the tunnel wall - not the detour) it is pushed away as a user error. I agree that calculating a route is hard, no doubt. But there is a degree of lets say miscalculation I still would consider wrong. Again, leaving a motorway through a underground tunnel wall - I would call wrong. Of course nobody in his right mind would attempt it when sitting in his/her car ... but it is pretty annoying to wait for the app to recalculate a different route that may or may not be better that the mistake calculated the first time.
To sum it up, I am not trying to be mean, or annoy any of you. I just think the route suggested by Osmand is so far off anything considered an acceptable route that it needs improvement. I am willing to help and provide the details in a degree I thought is enough. If you need more to improve the routing, I am happy to help. If there really is an issue in the OSM data, please tell me exactly what it is and I am willing to fix it or at least try to get someone to fix it, if I can not do it myself.
If you insist the Users are the problem, Please let me know. In such a case, we have reached an in-pass which we will never fix. I thought it would be worth helping to improving Osmand as I thought, besides the routing, it is one of the best Android apps for OSM data. Most of the time I use navigation and map apps to find either the best route to a known destination or often find a route to a destination in unknown areas. Both situations would make it very difficult for the amount of "sanity check" suggested.
I hope we can leave the emotions out of it and focus on a way to fix this issue either in Osmand or the OSM data. I am willing to help and I hope you are willing to work on it too.
gerhard-tinned
commented
2 years ago Little Add on, I even tried to use a different OSM app with offline routing (the name of that app does not matter at this point) and tried to find the mistake in the in the OSM data.
I would have expected to see a similar issue with the routing as in Osmand if the OSM data is would be the issue. But the alternative app in that case even suggested 3 possible routes all either exiting the motorway on a regular exit before or after the area of the destination. None of them tried to exit ... well, through the tunnel walls (sorry, not the most scientifiy name for it but that is basically what Osmand suggests).
scaidermern
commented
2 years ago This is essentially a duplicate of #1578. There have been various similar reports (#5395, #7449, #7520 and others).
For now you always have to check the destination marker and move it slightly to the correct location, when required. In fact, you should always perform this check, with all navigation apps.
gerhard-tinned
commented
2 years ago Startpoint: Schlachthammerstrasse 97, 1220 Wien Endpoint: Stadlauer Straße 41A/Hof 4, 1220 Wien
It took quite a while to find these on the (Web) map. Nominatum wasn't able to resolve the destination string.
In future, supplying coördinates or (better) a link would be far less ambiguous (perhaps the report template needs to be updated).
In the course of my digging, I yielded the original route (matching the OP). However, when changing the destination only slightly (by a couple metres) (and changing nothing else) the optimal route was yielded.
So, how exactly was that destination given to OsmAnd?
I checked the links you sent for the route. And it seems you have used some coordinates in the area of the destination. I used the test label in the destination and ... well, the expected route came up. I do not understand why the route does not work for the coordinates just a few meters away.
It is I think not OK to end the route in the middle of an underground motorway tunnel in any situation but ... at least the route I explained in the beginning works in the Car (OSRM) and the Car (GraphHopper) when the correct address is entered. It just does NOT work in the Osmand app.
gerhard-tinned
commented
2 years ago This is essentially a duplicate of #1578. There have been various similar reports (#5395, #7449, #7520 and others).
For now you always have to check the destination marker and move it slightly to the correct location, when required. In fact, you should always perform this check, with all navigation apps.
As stated multiple times, that is possible if you knoe the best route or the destination area. But it does not work so well if you are in a country you do not know or drive into a reagion you do not know. And honestly that is the main reason to use an app like that.
Of course, you will never be 100%, I get that. but there is a difference between having it 80% right and at least having the end point of the route in a place where there is even a remote chance of beeing able to stop (like a normal street) instead of having it 80% wrong and end in a tunnel on the motorway where (I believe in all countries) you can not really stop or park or ... well, you get the point.
So at the end, do you consider this an issue with the routing engine or how to continue from here?
scaidermern
commented
2 years ago For now you always have to check the destination marker and move it slightly to the correct location, when required. In fact, you should always perform this check, with all navigation apps.
As stated multiple times, that is possible if you knoe the best route or the destination area. But it does not work so well if you are in a country you do not know or drive into a reagion you do not know.
Well, I think it is rather obvious that you don't want your journey to end in a tunnel. You don't need to know the destination area for that.
So at the end, do you consider this an issue with the routing engine or how to continue from here?
Sure. #5395 has a milestone set for the 4.2 release. Let's hope for the best.
vshcherb
commented
2 years ago This is the route we talk about https://www.openstreetmap.org/directions?engine=fossgis_osrm_car&route=48.2153%2C16.5219%3B48.2333%2C16.4560#map=17/48.23200/16.46101
The problem is not the route itself but the point "48.23320, 16.45609" which attaches to the motorway instead of private road. It's an issue related to customer roads: access=destination have very low priority. https://www.openstreetmap.org/way/177654760
gerhard-tinned
commented
2 years ago This is the route we talk about https://www.openstreetmap.org/directions?engine=fossgis_osrm_car&route=48.2153%2C16.5219%3B48.2333%2C16.4560#map=17/48.23200/16.46101
The problem is not the route itself but the point "48.23320, 16.45609" which attaches to the motorway instead of private road. It's an issue related to customer roads: access=destination have very low priority. https://www.openstreetmap.org/way/177654760
That is an interesting comment. Specifically because the destination "Werksalon Co-Making Space GmbH" or also by address "Stadlauer Straße 41A/Hof 4, 1220 Wien" has the location "48.2329692, 16.4560617".
https://www.openstreetmap.org/node/4396476837
In both nodes related to the "Werksalon ..." which are a Jopiner and an Entrance show the address details for the main street "addr:street=Stadlauer Straße".
Or do you realy mean the tags at the street (https://www.openstreetmap.org/way/177654760) you outlined? Shouldn't the address of the destination address / destination object define the access? Or am I mistaken? If it is the street that has the wrong tags, please let me know and I will try to get this changed in accordance to the OSM rules and practice.
vshcherb
commented
2 years ago My theory: if https://www.openstreetmap.org/way/177654760 woulnd't have access=destination such bug wouldn't exist but that needs to be checked properly.
scaidermern
commented
2 years ago It is not uncommon that a destination is located in a access=destination area.
(actually access=destination sounds wrong, most of the time it should be vehicle=destination or motor_vehicle=destination).
gerhard-tinned
commented
2 years ago It is not uncommon that a destination is located in a access=destination area.
(actually access=destination sounds wrong, most of the time it should be vehicle=destination or motor_vehicle=destination).
What is the meaning of those tags? Can you point me to an explanation or something?
scaidermern
commented
2 years ago It is not uncommon that a destination is located in a access=destination area. (actually access=destination sounds wrong, most of the time it should be vehicle=destination or motor_vehicle=destination).
What is the meaning of those tags? Can you point me to an explanation or something?
Check https://wiki.openstreetmap.org/wiki/Key:access. Not every combination is described explicitly but the concept stays the same. The destination value means "Only when travelling to this element/area", "no thru traffic" etc. The key defines for which transportation modes this restriction applies. access=destination means it applies for everyone, i.e. even pedestrians. That's why access=destination is rarely correct. vehicle means it applies to all vehicles (cars, bicycles, ... but not pedestrians). _motorvehicle means it applies to motorized traffic only (cars, motorcycles, but not bicycles and pedestrians).
Lee-Carre
commented
2 years ago actually
access=destinationsounds wrong, most of the time it should bevehicle=destinationormotor_vehicle=destination
access=destinationmeans it applies for everyone, i.e. even pedestrians. That's whyaccess=destinationis rarely correct.
While I
access=* is (often) too broadI have encountered some places which were definitely access=destination (and maybe access=private) including for pedestrians. A memorable one was (as far as I could determine) also noexit=yes. So the restriction also applying to pedestrians made sense; why would pedestrians (need to) enter unless they were visiting an occupant of that location?
Though, I suppose one could disambiguate by setting multiple access sub-keys to destination:
foot=destination
vehicle=destinationAs a surveyor, to give a little insight: aside from the case of a mapper not knowing about (or how to use) specific sub-keys, sometimes it's quite unclear what the exact rules are, even when there's signage. Sometimes there's only a sign which reads “PRIVATE”. Private for who or what? It didn't specify.
So, besides ambiguity, given OSM's principles of what's-on-the-ground & verifiability, I can see why access=* may be set, sometimes.
I've encountered numerous situations which make me question ‘how do I tag this?’ (some are real head-scratches, even after doing research).
In other cases, it may be that other factors meant that detailed mapping wasn't possible at the time
I've been known to set barrier=yes due to some of the above factors. I deemed it better to mark that there was a barrier at all, than not. It can be refined later (since it's then a known concern).
I gather that many surveyors (particularly those using StreetComplete) don't like to stop to do detailed mapping.
Ideally, mappers setting access=* (as a quick & dirty measure; see above) would also set at least one of
note:accessfixme:accessso that the situation (ambiguity / incompleteness) is clear to other mappers.
Setting access at all (when it's restrictive), to indicate such, is better than leaving it unset. At least, then, it's identified / recognised as likely needing refinement.
Otherwise, it has to wait until the next surveyor discovers it. Some areas have very few mappers / surveyors, so that could be a very long time.
gerhard-tinned
commented
2 years ago I got in contact with the OSM community and checked the signs on side. It was suggested to set "access=permissive".
It seems now Osmand now routes as expected. Thanks. Still, I think ending the route on a motorway, specially in a tunnel should be changed.
And even with the wrong tag, I would have expected to see the route end at the next closest street - which is not the motorway and or a tunnel.
JenswBE
commented
2 years ago Facing a similar issue. Unfortunately, it's unclear if I should consider it a routing issue or a data issue. So, please feel free to point me to OSM community if you consider it a data issue or to create another PR in case you consider it another issue.
Starting point: 51.02120 N, 4.44816 E Destination point: 51.18348 N, 4.39170E (reproducible with quite some points, see below screenshots) Same OsmAnd version, routing, maps, ... as original PR. Only difference I'm on Android 12L (crDroid 8.4 on Samsung S10)
Problem When trying to navigate to parking "P+R Olympiade", OsmAnd routes to an underground highway tunnel instead of the parking on top. This is reproducible with different points around the parking. Routing is correct on OSMR and GraphHopper: https://www.openstreetmap.org/directions?engine=fossgis_osrm_car&route=51.02814%2C4.48035%3B51.18340%2C4.39177#map=19/51.18300/4.39200
Routing to parking node:
Routing to a public transport stop nearby:
Explicit routing to a road of the parking:
Explicit routing to the access road of the parking:
Routing to another public transport stop nearby works correctly:
Tagging on the access road of the parking. My doubt if it's a mapping error is because I can reproduce with the public stop (see screenshot 2 and 3):
More info on why the tagging of the access road seems correct:
vshcherb
commented
2 years ago @JenswBE ! It looks like we could deprioritize tunnel a lot cause almost nobody wants to have final point in the middle of a tunnel !
We need to update detection mechanism here - https://github.com/osmandapp/OsmAnd/blob/master/OsmAnd-java/src/main/java/net/osmand/router/RoutePlannerFrontEnd.java#L175
alisa911
commented
2 years ago java https://github.com/osmandapp/OsmAnd/pull/14473 c++ https://github.com/osmandapp/OsmAnd-core-legacy/pull/95 res https://github.com/osmandapp/OsmAnd-resources/pull/831 Checked all cases in this issues Also was checked on https://github.com/osmandapp/OsmAnd/issues/7456
Not found cases for this commit https://github.com/osmandapp/OsmAnd/commit/21d2da32f3bba601df026940c2ea7f593fd6a041
vshcherb
commented
2 years ago We need to fix if section is not present at all in routing.xml
JenswBE
commented
2 years ago Big thanks @alisa911 and @vshcherb for following up and fixing this :heart:
🐞 routing report
This is partly linked to "OsmAnd is not choosing the optimal route" #13356 .
Routing engine
Routing Profile
Car routing profile
Start and end points
Startpoint: Schlachthammerstrasse 97, 1220 Wien Endpoint: Stadlauer Straße 41A/Hof 4, 1220 Wien
Details
Actual and expected routes
The route calculated by Osmand is about double as long in distance and time. Additionally, the route leads literaly onto the highway and exiting trough the tunnel walls - there is no exit. In short, it is impossible to follow that route!!!
Details
I have used a different openstreet map based routing app to show the correct route.
Details
Is this a regression?
Yes, the previous version in which this bug was not present was: .... I do not know if this particular route works in previous versions. I do know that I had overly long routes and huge detours in the routing in the past. ## 🌍 Your Environment **OsmAnd Version:**Device and Android/iOS version: 11 (OxygenOS 11.0.
Maps used (online or offline):
Anything else relevant?
Is there any way to fix that broken route calculation or use a different routing engine???