NOTICE: help.openstreetmap.org is no longer in use from 1st March 2024. Please use the OpenStreetMap Community Forum

Background:


http://wiki.openstreetmap.org/wiki/Relation:boundary describes boundary relations, with the parent article http://wiki.openstreetmap.org/wiki/Boundaries explaining:

'The original accepted usage was to only apply (the boundary) tag to areas. However there now seems to be a consensus of using the boundary key also on linear ways, with relations used to aggregate these ways if needed.'

http://wiki.openstreetmap.org/wiki/Place#Administrative_boundaries is the best description I can find of how to do this. It prescribes (one boundary relation) (per administrative boundary), which will have:

  1. One or more ways of role 'outer'/'inner', which themselves are tagged with boundary and admin_level tags
  2. Zero or one nodes of role 'admin_centre', for the 'center' of the administrative area
  3. Zero or one nodes of role 'label', indicating where the label for the administrative boundary should be rendered

As best I've found, none of the above talks about where place related tags should go, prescriptively. Obviously we would like to avoid having the same information, possibly with different values, dumped into different places. So! My question is, "in an ideal world", where do tags like the following belong, picking one place for them?

population, ele, name, wikipedia, is_in, gnis, tiger, place

I realize that because both methods are "in the wild", our tools have to expect them to be in either place, and that's not really what I'm asking here. My question is, when a human editor is editing or performing cleanup, do the tags belong on the administrative boundary relation itself, or on a point (likely with the 'label' role) meant for this purpose?

Thanks for any insight!

asked 30 May '14, 03:29

Skybunny's gravatar image

Skybunny
60226
accept rate: 0%

edited 30 May '14, 03:30


Those tags, excepting the ele tag as already answered by cartinus, would go on the area describing the place. Whether that's a single closed way surrounding the "place", or a multipolygon combining multiple ways, that's the object defining the place. The constituent boundary ways themselves obviously don't have a population, for example, though some notable ones do have Wikipedia articles (eg. Canada/US, US/Mexico, etc.).

BTW, is_in is generally considered unnecessary now. A determination of whether an object resides within another can be determined from their geographical relationship (ie. the coordinates for this object reside within this other area), so is_in is redundant. It isn't wrong to use it, though.

permanent link

answered 30 May '14, 17:49

alester's gravatar image

alester
6.6k266100
accept rate: 28%

edited 30 May '14, 17:49

Okay! I think I gather from this:

When an administrative zone is ONLY specified with a point (typically place imports that need upgrading anyway), then by definition, all tags for are on that point.

However, when the better-refined administrative item now has 'an area', or 'a border relation' (it doesn't matter which), tags related to that (entire) administrative boundary belong on those and should be moved there.

Then it follows, nodes that exist for that administrative boundary relation with the admin_centre or label roles should NOT have those labels.

Have I got this right?

(30 May '14, 21:54) Skybunny
1

Please don't go around removing them automatically from the admin_centre. (Not that you said so, but...) The values on it could be for the place itself and not the whole administrative area.

(31 May '14, 04:35) cartinus

I'll answer the obvious one below. The rest of your question will most likely invoke a long debate that isn't suitable for this site and should probably be held at the tagging@ mailing list. (See the FAQ.)

Administrative area's don't have a single elevation. Labels are "virtual", so they don't have an elevation at all. Only the admin_centre node can have an elevation.

permanent link

answered 30 May '14, 04:33

cartinus's gravatar image

cartinus
7.0k1066105
accept rate: 27%

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:

×236
×191
×92
×43
×37

question asked: 30 May '14, 03:29

question was seen: 3,568 times

last updated: 31 May '14, 04:35

NOTICE: help.openstreetmap.org is no longer in use from 1st March 2024. Please use the OpenStreetMap Community Forum