Opened 5 years ago

Closed 5 years ago

#5126 closed defect (wontfix)

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

Reported by: jalek Owned by: rails-dev@…
Priority: minor Milestone:
Component: website Version:
Keywords: Cc:

Description

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.
  1. 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.

Change History (5)

comment:1 Changed 5 years ago by Sarah Hoffmann

Component: nominatimwebsite
Owner: changed from geocoding@… to rails-dev@…

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.

comment:2 Changed 5 years ago by Tom Hughes

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!

comment:3 Changed 5 years ago by Tom Hughes

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?

comment:4 Changed 5 years ago by Sarah Hoffmann

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.

comment:5 Changed 5 years ago by Tom Hughes

Resolution: wontfix
Status: newclosed
Note: See TracTickets for help on using tickets.