osmandapp / OsmAnd

OsmAnd
https://osmand.net
Other
4.63k stars 1.01k forks source link

Building polygons are not taken into account during Reverse Geocoding #13628

Open woodmiser opened 2 years ago

woodmiser commented 2 years ago

Description

This seems to be a systemic problem either with the app or the way that OsmAndMapCreator creates the maps. The program seems to be locating business addresses on the basis of building proximity to nearby nodes. I'm not a developer, just an OSM map contributor, so I don't know exactly how the process works. But I did run across this technical article at https://osmand.net/help-online/technical-articles which gives an overview of the process. If I'm reading this correctly, it finds the borders of a building and then registers it for the street. Then later, in step 6. it iterates nodes, ways, and relations then it says "skip if building for this entity already exists! To my mind at least, that's backwards. It seems to me that it should find addresses from the openstreetmap data first, and then only then make a guess by associating the building to a nearby node if it can't find the information in the tag data. Or, if you want to continue locating bases on nearby nodes first, at least replace the building address with the correct one from the OSM data when that information is processed, instead of skipping it after the incorrect information has been applied. It's not a problem with Nominatum. I checked that and it has the information correct. I'm going to give one example, but I could give lots more. This is a Kohl's department store. The program has reached out and grabbed a node belonging to an adjoining property, owned by someone else, not even connected with the store or the shopping center, and applied it to the store. The address, from Nominatum is Kohl's, 2110, Highway K, O’Fallon, Saint Charles County, Missouri, 63368, United States. The node id at the corner of the building is 1728253769. Its corrdinates are 38.7798953, -90.6954704. The node id of the unrelated address it grabbed is 6358025373. Its coordinates are 38.7798384, -90.695075. The address of that property is 397 Laura Hill Road The program should not be locating addresses of buildings based solely on proximity to nearby nodes. Things cannot continue this way. It does not work. It will not work. EVER. It needs to be chaned, and until it is, OsmAnd will remain pretty much useless and even dangerous for first responders to use in emergency situations. And as openstreetmap data continues to mature, I see more and more services using this data. We mappers can only give you data. It's up to you to process it appropriately.

How to reproduce?

Go to the coordinates I referred to. This is in O'fallon, Missouri, United States. You will see the Kohl's department store. Click on navigation. Choose My position. Choose "select on map", and click on a nearby location across Highway K. Do the same for destination, only click on the kohl's store. Start the navigation in demo mode. The voice takes you to Laura Hill Road, and when it gets to the building, it doesn't even wait for a street. It turns and crashes straight through the side of building. Then when it gets to the center of the building, she announces "Attention! Stop sign". It's hilarious! I laughed so hard my sides hurt!

Your Environment

OsmAnd Version: 4.1.11 Android/iOS version: Android 9 Device model: Samsung Galaxy Tab A

Maps used (online or offline):
If you have an issue related to offline maps, tell us the exact name of the map file where the issue occurs and its edition date. I first noticed the problem with a map I built from OsmAndMapCreator, using data I downloaded from GeoFabrik on 24 January, 2022. But then I switched back to the map of Missouri that came with the OsmAnd app to see if the problem was there also, and it is. The name of the file is Missouri-latest.obf in both cases.

vshcherb commented 2 years ago

This part of documentation is deprecated, here is new one https://docs.osmand.net/en/main@latest/development/algorithms/trace-address-search-issues.

Indeed OsmAnd doesn't recognize boundaries of the buildings which works incorrectly for large buildings. In emergency cases anyway it's better to use precise coordinates instead of address like Google OLC code