Hi, the kolonieweg on this place: http://www.openstreetmap.org/?lat=52.05471&lon=6.08128&zoom=16&layers=M

You can find this way only if you search for: Kolonieweg, Bottrop, Deutschland

Instead of Kolonieweg, Dieren, Nederland

How can i change this?

asked 18 Mar '11, 12:58

Vasco's gravatar image

accept rate: 0%

edited 25 Mar '11, 11:46

TomH's gravatar image

TomH ♦♦

Just a note: searching for "Kolonieweg, Dieren" now does find the right street. However, in the list of search results the street is still listed as "Kolonieweg, Bottrop, Germany". So the problem was apparently fixed partially.

(23 Mar '11, 09:29) sleske

Note 2: Searching for "Kolonieweg, Dieren" now finds the right street, and lists it as being in Dieren, Nederland. So it's fixed now :-).

(29 Mar '11, 03:12) sleske


This type of problem usually occurs if the information about where the way is situated (inside which administrative boundary) is not correct.

You can debug this by repeating the search on http://nominatim.openstreetmap.org/ (Nominatim is the search engine behind the search on openstreetmap.org).

You get the same results, but here you can click on "details" to find out how Nominatim reached its result. Doing so, you get a map showing you the OSM object that Nominatim found for "Dieren", along with some details. There you can see that:

a) The city of Dieren exists as a real polygon in the OSM database, i.e. its exact boundaries are in the database. However, the boundaries of the city of Dieren in the OSM database do not include the Kolonieweg (they end just short of it). So its clear that searching for "Kolonieweg, Dieren" does not work.

b) For some reason, Nominatim seems to believe that Dieren and its surroundings are part of Bottrop (Germany). So from that point of view it's correct that you need to search for "Kolonieweg, Bottrop".

So to answer your question:

  • The boundaries of Dieren in the OSM database need to be corrected (if the Kolonieweg really is inside Dieren).
  • For some reason Nominatim believes that Dieren is in Bottrop. Maybe someone else here can clarify why, otherwise a bug report against Nominatim should probably be filed.


I misunderstood the data in the database. There are two areas/polygons named "Dieren": one is a "place=village", and the other a "boundary = administrative". The "place=village" one does not include Kolonieweg, but the other one does, and that's enough for Nominatim. Thus there's no need to change anything.

permanent link

answered 18 Mar '11, 13:59

sleske's gravatar image

accept rate: 25%

edited 24 Mar '11, 17:45

I don't agree that the place-way for Dieren should be extended. (Well, there is an "error" in classifying Dieren as "city" which would have to be modified, but that's not the question here). Talking about this way: http://www.openstreetmap.org/browse/way/6336691 Additionally there is a node for Dieren (place=town). I suggest to delete the node and to change place=city to place=town on the polygon.

The administrative boundary for Dieren is including the way: http://open.mapquestapi.com/nominatim/v1/details.php?place_id=2108081540

(18 Mar '11, 16:01) dieterdreist

@dieterdreist: Try the search "dieren" on nominatim.openstreetmap.org. The first three results I get are: "Dieren, Bottrop[...]", "Dieren, Stadsregio Arnhem[...]", "Dieren, Rheden, [...]". If you click "details" on each, each will show you a map with "Dieren" marked, all three different! So there seem to be multiple "Dieren" in the database...

(23 Mar '11, 09:21) sleske

BTW: I'd appreciate a comment about the downvote. Is there any factual error in my post?

(23 Mar '11, 09:22) sleske

@sleske: Yes, there were 2 Dieren places, one as node, one as area, I removed the node (and copied tags to the area that were only on the node). Then there was an administrative boundary which I left untouched and which included the Kolonieweg. You should not extend the place area to the Kolonieweg as it apparently seems to be uninhabited and not built up space.

(23 Mar '11, 10:00) dieterdreist

@sleske: yes, you said:"The boundaries of Dieren in the OSM database need to be corrected (if the Kolonieweg really is inside Dieren)." but this is not the case. The boundary of Dieren seems correct and closed. The Kolonieweg is inside. It is not inside the place-polygon, but this is OK (see also comment before).

(23 Mar '11, 19:16) dieterdreist

@dieterdreist: Ah, I see, there are two areas/polygons named "Dieren": one is a "place=village", and the other a "boundary = administrative". The "place=village" one does not include Kolonieweg, but the other one does, and that's enough for Nominatim. I edited my answer.

(24 Mar '11, 17:44) sleske

@dieterdreist: A final question: Why did you delete the node with "place=village", and kept the area? According to http://wiki.openstreetmap.org/wiki/Key:place it is recommended to have a place node + an area with "boundary=administrative", and not areas for both place and boundary. Or is that advice outdated?

(24 Mar '11, 17:51) sleske

@sleske: sorry, there's a bug in the system, I cannot cancel the down vote (because of your recent edit), because I get an alert that I cannot cancel a vote older than 1 day.

(24 Mar '11, 22:45) dieterdreist

@dieterdreist: No problem, I'll probably get some rep eventually :-). BTW, I asked a separate question about the place/boundary thing: http://help.openstreetmap.org/questions/4068/when-does-it-make-sense-to-use-place-on-an-area

(25 Mar '11, 11:45) sleske
showing 5 of 9 show 4 more comments

It seems you have caught a problem in the implementation/set up of nominatim: it is interpreting place=region on a node with high importance, while this is a tag where it seems it is not even clear what the meaning is: http://wiki.openstreetmap.org/wiki/Tag:place=region, and while there are "exact" boundaries available without having to guess about the extension of a node place=region. (which is the reason - maybe together with the temporarily broken boundary between Holland and Germany - that Dieren is located in Bottrop)

permanent link

answered 18 Mar '11, 16:09

dieterdreist's gravatar image

accept rate: 3%

There was a problem with some places being assigned to the wrong country during the original import. Since then a lot of the data has been fixed but there are still some places that have not yet been re-indexed to fix this. I will add this area to the list and run it tonight.

New data and modified data should all be correct. Existing data is being fixed slowly.

permanent link

answered 18 Mar '11, 13:58

twain's gravatar image

accept rate: 40%

Looking at the data the boundary relation (for Dieren) seems to be correct. I guess there was recently a problem somewhere (maybe a broken boundary between the German and Durch border) which caused Nominatim (the search application used on OSM main page) to not be able to locate Dieren correctly. I suggest to wait for the next Nominatim data update to see if the problem persists. See here for more details: http://wiki.openstreetmap.org/wiki/Nominatim

Additionally I checked the Bottrop relation and it seems to be OK as well (it forms a closed way).

permanent link

answered 18 Mar '11, 13:37

dieterdreist's gravatar image

accept rate: 3%

edited 18 Mar '11, 13:47

http://open.mapquestapi.com/nominatim/v1/details.php?place_id=14638314 seems to list the Dieren town node rather than the admin_level=10 relation (though I can't confess to understanding how it works). Similarly it seems to list the Bottrop region node rather than the relation I've not looked for yet.

(18 Mar '11, 13:51) EdLoach ♦

This is maybe a misconfiguration? While it might be useful in less complete areas to take into account nodes with place=region as well, it surely doesn't make sense with boundary relations available.

(18 Mar '11, 13:55) dieterdreist
Your answer
toggle preview

Follow this question

By Email:




Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • numbered list: 1. Foo 2. Bar
  • basic HTML tags are also supported

Question tags:


question asked: 18 Mar '11, 12:58

question was seen: 6,006 times

last updated: 29 Mar '11, 03:12

powered by OSQA