This repository has been archived by the owner on Jul 24, 2021. It is now read-only.
Postal code mishandled #4852
Assignees
Comments
|
Author: lonvia Taking the postcode from the enclosing relation works now, e.g. on [http://nominatim.openstreetmap.org/details.php?place_id=5996745180 this place]. Avenue Alsina is a bit of a special case because it goes through two suburbs and Nominatim has put it in Lomas de Zamora. So, everything on the road gets the postcode from there not Banfield. That is a known (different) problem you could circumvent by splitting the road at the suburb boundary. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Reporter: nicolas17
[Submitted to the original trac issue database at 2.24pm, Wednesday, 1st May 2013]
Searching for anything in Banfield, such as [http://nominatim.openstreetmap.org/search.php?q=Av+Alsina+950 Av Alsina 950] ([http://nominatim.openstreetmap.org/details.php?place_id=5989203693 place]), always returns the post code B1832AHQ (unless the object has an explicit addr:postcode of its own). According to taginfo, the only usage of the post code B1832AHQ is on a [http://openstreetmap.org/browse/way/170042601 certain building] ([http://nominatim.openstreetmap.org/details.php?place_id=91722766 place]), but Nominatim seems to apply it to everything in [http://openstreetmap.org/browse/relation/2400639 Partido de Lomas de Zamora].
For the case I quoted in Alsina 950, I would expect it to get the postcode from the enclosing [http://openstreetmap.org/browse/relation/2537834 Banfield boundary relation].
([http://openstreetmap.org/browse/relation/2537834 Banfield] and [http://openstreetmap.org/browse/relation/2537822 Lomas de Zamora] are inside [http://openstreetmap.org/browse/relation/2400639 Partido de Lomas de Zamora])
The text was updated successfully, but these errors were encountered: