Skip to content
This repository has been archived by the owner on Jul 24, 2021. It is now read-only.

addr:interpolation - Nominatim calculates intermediate address but then opens up endpoint address #5126

Closed
openstreetmap-trac opened this issue Jul 23, 2021 · 4 comments

Comments

@openstreetmap-trac
Copy link

Reporter: jalek
[Submitted to the original trac issue database at 7.56am, Thursday, 20th February 2014]

Operating system - OSX 10.9.1 and Ubuntu 13.10
Browser - Firefox (both OS), Safari (OSX)

http://www.openstreetmap.org/


Problem description

In a previous release of www.openstreetmap.org, I could search on an intermediate address from a set of addresses that have addr:interpolation end tags. When I selected the intermediate address from the search results, the osm app would calculate the relative expected position of the address along the interpolated way and would zoom in to that position with a highlighted red circle.

Now when I select the address from the search results, it just zooms into the nearest end-point address as described in the example below:-

  1. The street Heriot Row in Edinburgh UK has addr:interpolation tags for the 2 end nodes (with values 1 & 19) and a connecting way.

  2. I enter '9 heriot row edinburgh uk' in the search box

3.Nominatim returns:-

House 9, Heriot Row, New Town, City of Edinburgh, Scotland, EH2 1DR, United Kingdom

4.I select "House 9, Heriot Row....."

5.The attributes for node 2173909689 for 1 Heriot Row is returned with an orange circle around the 1 on the map. Previously, this would have estimated the position for no 9 Heriot Row and displayed that address on the map instead.

Let me know if you need more info to investigate this. Thanks.

@openstreetmap-trac
Copy link
Author

Author: lonvia
[Added to the original trac issue at 6.59pm, Friday, 21st February 2014]

The behaviour of the website has changed with respect to interpolation points. You can see on Nominatim's website that it returns the correct coordinates for the address:

http://nominatim.openstreetmap.org/search.php?q=9+Heriot+Row+Edinburgh+UK&polygon=1

In the XML, Nominatim returns the correct coordinates as well but also returns the OSM object id of one of the interpolation points because it is the closest to the address. It does initially zoom in on the right coordinates but then moves to the interpolation point (at least when it is outside the viewport), which is admittedly rather unexpected.

I'm not quite sure what's the best solution here. Nominatim simply could stop returning an OSM object for interpolated addresses. I believe the website will then do the right thing and put a marker on the coordinate. However, I'm reluctant to do that as there might be applications that rely on the current behaviour.

@openstreetmap-trac
Copy link
Author

Author: TomH
[Added to the original trac issue at 7.25pm, Friday, 21st February 2014]

But equally, what exactly do you expect us to do about it? If the search result says that the search corresponds to a specific object then we will show that object!

@openstreetmap-trac
Copy link
Author

Author: TomH
[Added to the original trac issue at 7.26pm, Friday, 21st February 2014]

Surely where an interpolation is involved nominatim should return the ID of the interpolation way, as that is the object from which it has derived the location?

@openstreetmap-trac
Copy link
Author

Author: lonvia
[Added to the original trac issue at 9.11pm, Friday, 21st February 2014]

One can certainly find good arguments for concluding that it is derived from the interpolation way or the interpolation address or no OSM object at all. The current interpretation goes for the address point and returns the interpolated coordinate as well. That might not be ideal but it is perfectly valid and, more importantly, the current state of the nominatim API. I wouldn't classify it as a bug.

The website used to respect the coordinate that nominatim returns in the search result. It was decided to get rid of that, fine. But it also means the site now somehow has to handle these corner cases by itself.

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

No branches or pull requests

1 participant