This is a static archive of our old OSM Help Site. Please post any new questions and answers at community.openstreetmap.org.

Nominatim, streets & administrative boundaries

3

I thought this had come up before but couldn't locate relevant past questions. Nominatim takes address info for POIs from their associated streets. This sometimes leads to incorrect results. I have two cases in mind:

  1. Streets can and often run through administrative boundaries. It seems that these streets will have to be split, in order for Nominatim to show each segment with the correct place information. If done, should the boundary and the street share the node at the split? Would this be considered tagging for the geocoder?
  2. How can we deal with cases where the (district) boundary follows the street? When this is the case, POIs on opposite sides would of course be in different districts, but since they are attached to the same street, it doesn't seem possible to get the system to work correctly here.

asked 05 Jan '14, 00:48

Paul_012's gravatar image

Paul_012
686●13●17●31
accept rate: 33%

2 Answers:

2

Even if Nominatim or other services fail at assigning multiple addresses to objects crossing administrative boundaries you should not split them at these points. As you already mentioned this is tagging/mapping for a specific service and consequently should be avoided. The only valid solution is to improve these services and fix such problems on the data consumer side.

answered 06 Jan '14, 12:21

scai's gravatar image

scai ♦
33.3k●21●309●459
accept rate: 23%

0

If I understand this page right, the indexing goes bottom-up. So i's invoked by the addresses itself and uses the tagged/closest road and the polygone/place radius area. So a road that crosses multiple boundaries can also be found in both cases and we don't need to split it.

(but please may nominatim experts call me wrong)

answered 05 Jan '14, 08:12

iii's gravatar image

iii
4.9k●8●40●82
accept rate: 10%

Based on some observations searching at nominatim.openstreetmap.org, this doesn't appear to be the case.

(05 Jan '14, 12:04) Paul_012
1

Maybe then a post (and updating the docs in the wiki) here might be a good choice: https://lists.openstreetmap.org/listinfo/geocoding

(05 Jan '14, 12:22) iii

iii, the page you mention also states "During the indexing process an address is also calculated using the first feature found for each level. Where an is_in value is provided it is used to filter the address."

So, it's always located in "the first"

(06 Jan '14, 12:01) escada