6
1

Motivation & Background

(I will try to explain everything leading up to the question, so if you don't want to read that, go straight to the last section.)

I noticed that Nominatim search results for South Korea was in a complete mess. So I'm in the process of doing a complete overhaul of the boundaries in the hopes of having a coherent and consistent structure.

Notes

The boundaries for the provinces and cities in this country is well-defined, and they can be directly correlated to place=* since major settlements all fall within city borders. So it's only a matter of putting up the boundaries and tagging appropriately, as far as the scope of my work is concerned.

Progress

I was able to create an entire administrative boundary for the country (admin_level=2; the old one was mostly redacted by the bot, but it was inaccurate anyway), as well as for all the provinces / metropolitan cities (admin_level=4).

Most recently, I placed the admin boundaries for all the cities / counties (admin_level=6) within the most populous province, Gyeonggi-do, with plans to expand this effort to other provinces. You can see that the country will have some relatively fine-grained administrative boundaries placed soon.

Problem!

I was initially making boundary relations that was tagged with boundary=administrative and admin_level=*. There were nodes tagged with place=* near the city centres, so I left them at that - they also seem to be where the map renderer puts the label. This apparently "used to be" how it should be done.

But then I noticed that Nominatim began to recognize both the boundary relation and the node, resulting in two search results, not one. The node result comes out as (city name), (city name), (province), (country) - the first one being the node, and the second one being the boundary relation. So this clearly wasn't what I wanted to achieve.

Upon further reading of this subject in the Help, Wiki, and other places, it seems that the "current" way to go about it is... when a boundary relation defining the area is created, move the place tag into it, and delete the node that originally had the tag. You don't want to duplicate data on two places in OSM, so I thought that sounded logical.

So I removed all the nodes containing the place=* tag for the provinces and added it to their boundary relations. This did solve the Nominatim search problem. When it was time to do the same for the cities, I noticed another issue - I would like to have the label near the city center, not somewhere in the middle of the defined area. You can define a node as 'label' in the boundary relation to do this, apparently.

However, there are lots of either outdated or conflicting info on whether a label would properly render at all. Some place says that 'label' node won't yet work, and you need a separate node with place=* tag in order for the place label to be rendered.

So the Questions are...

  1. Will the current OSM renderer put the province / city / etc. name on the center of the (administrative) boundary relations if it has a place=* defined? I know that a node with place=* will have its name rendered, so I want to know if this is true now for boundary relations, too.

  2. If so, will having a 'label' node in that relation let me position the label? Some old post mentioned this not being the case, so I'm hesitant.

  3. With the completion of national boundary relation (admin_level=2), it would only make sense that even the place=country tag should be added to the relation and have the separate node deleted, for the sake of consistency. Currently, the Wiki says that place=country should only be put in a node, but place=continent and place=state can be put in an area, so that doesn't sound consistent. Should I keep the node or not? This one is related to the previous questions, since I don't want the country label to go missing.

asked 12 Sep '12, 04:19

namuori's gravatar image

namuori
106124
accept rate: 0%


  1. OSM tiles do not currently render labels for relations

  2. No, this was the proposal but I don't believe it is implemented

  3. The country place node is far less useful that other nodes, but I would say for consistency should be included.

Its worth noting that Nominatim was recently (in the last 2 weeks) upgraded to handle duplicate node+relations pairs and to follow and merge data based on the label relation member. Given this my current recommendation would be:

  1. Create a node tagged place=* with suitable name/tags at the central location of the admin feature (this may not be the geometric center, but rather the place that would subjectively by thought of as the center)
  2. Create an administrative boundary relation with admin_level defining the boundary of the feature in the normal way
  3. Add a 'label' member to that relation linking the label node and the relation (nominatim and other data users can use this to deduplicate data)
  4. Add a wikipedia tag to either the node or relation to allow Nominatim to work out the importance of the feature

This would be my current gold standard for admin data to best work with both Nominatim and tile rendering while avoiding 'tagging for the renderer'.

permanent link

answered 12 Sep '12, 13:21

twain's gravatar image

twain
2.4k2538
accept rate: 40%

edited 12 Sep '12, 14:19

To avoid duplicates in Nominatim, your forgot to mention the new feature with the role "admin_centre" in the boundary relation linked to the "place" node (the one which is the administrative centre e.g. the capital for a country or a town or city for a region, province, county or municipality).

(12 Sep '12, 14:08) Pieren

No, for things that are exactly the same you should use the 'label' relation member. admin_centre is for things like 'Sheffield (node)' is the admin_centre of 'South Yorkshire (relation)'. label is for things like 'Sheffield (node)' is the label for the 'Sheffield (relation)'

(12 Sep '12, 14:12) twain

I didn't speak about label issue but Nominatim search results duplicates as mentionned in the question. admin_centre has to point to the related administrative place, nothing to do if it is 'exactly the same' or not. If you understand it like this, then I failed to document it on the wiki (yes I created this role a long time ago).

(12 Sep '12, 15:47) Pieren

yes, my understanding is that admin_centre points to a a related feature (which may or may not have the same name, but is definitely not the exact same place). The question asks about duplicated data i.e. where we have both a place=* node and a boundary=administrative relation for exactly the same place and how to avoid/handle this duplication. In context admin_centre is not relevant although it may be additional useful information to add to a relation.

(12 Sep '12, 16:24) twain
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:

×548
×165
×72
×72
×38

question asked: 12 Sep '12, 04:19

question was seen: 4,548 times

last updated: 12 Sep '12, 16:25

powered by OSQA