Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Return the bigger object matching searched address #3589

Open
ls-1N opened this issue Nov 14, 2024 · 2 comments
Open

Return the bigger object matching searched address #3589

ls-1N opened this issue Nov 14, 2024 · 2 comments

Comments

@ls-1N
Copy link

ls-1N commented Nov 14, 2024

What did you search for?

What result did you get?

Small sheds or garages.

What result did you expect?

For both of them, I expected the bigger and more important residential buildings next to them with identical addresses.

When the result in the right place and just named wrongly:
No. But FYI, this ⬆️ template subpoint should maybe have the word "is" 😛. Same for the one below it.

When the result missing completely:

Further details

This is an issue I have noticed a lot when using openstreetmap.org in Tartu. I think the issue is nonexistent or less pronounced with OsmAnd~. The issue does not appear for each set of objects without a unique address - i.e. for some queries Nominatim returns the bigger object (residential building). An example being Vaba 22.

  1. Is this an unfortunate side-effect of implementation details that cannot easily be fixed?
  2. Is this something that can be improved on the Nominatim side?
    2.1 E.g. if multiple results with the same address, return the largest object first? However, this would only really help if there is access to an approximation of surface area. Sometimes the bigger (and usually more important) building has fewer nodes than the small side building. Ofc few buildings have their height or floor tags added, so can't base it off of that either. 🤔
  3. Should all of these hundreds or thousands of map objects simply be edited in the OSM dataset? What should be changed?

I'm terribly sorry if this has been asked before. I searched for some issues here before being overwhelmed 😞. But I ultimately decided to attempt to contribute anyway since this has subjectively been the most glaring issue with OSM usability in the browser. 😅

@lonvia
Copy link
Member

lonvia commented Nov 14, 2024

Somewhat related to #3444. I need to figure out why Nominatim has this obsession with taking the smallest possible object when deduplicating. I'd expect it to return the largest one just like you say.

That said, the duplication of addresses in that area is somewhat odd. Addresses are usually related to an entrance and I'd expect only the building containing the entrance to have the address tagged. But that is more a discussion for the local community than for this issue tracker.

@ls-1N
Copy link
Author

ls-1N commented Nov 14, 2024

Thank you!

That said, the duplication of addresses in that area is somewhat odd. Addresses are usually related to an entrance and I'd expect only the building containing the entrance to have the address tagged. But that is more a discussion for the local community than for this issue tracker.

I suspect that is the result of importing a public dataset that also has an address duplicated for every building on a particular lot (unless they have their own distinct address). Whether it is a quirk of the specific data source or whether the whole legal apparatus sees the addresses this way, I cannot guess.

But I hope the the pairs of buildings on Vaba street might be easier to examine for correlations than several pieces of a road.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants