|
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:
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! |
|
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. 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. |
