Talk:Proposed features/place areas
KISS : reuse an existing model boundary=place
In short: if you want to tag boundaries, use the model for boundaries! That's it.
Tagging an official boundary is made using a relation. It works, and well. Just add the boundary=place for possible boundary usage. See https://wiki.openstreetmap.org/wiki/Relation:boundary for details and advantages of this model compared to yours (left:name and similar are not needed for instance if two places have a common boundary, you boundary checkers etc...).
Why trying to map a similar feature (a non official boundary) using a different model? It would just make OSM harder to use. On top of that some such places like neighborhoods may a official in some places, not official elsewhere. If an informal boundary becomes formal we would have to remap instead of changing the boundary type.
The idea that relations would be too complex doesn't last as the potential issue is a tool issue. If a simple relation is too complex for the contributor or the contributor has too little knowledge of OSM or s-he hasn't found the right to create the relation. You need to sketch a (multi-)polygon (boundary) and/or a node (the center) and give them a name. A single name (in your proposal you would have to duplicate the info like possibly others (population...). And that's it.
The tool can create the relation. For instance [comcommaker] aggregate boundaries to create new entities without need of relation knowledge.
I do have what I hope is some constructive criticism of this proposal, and also something that TBH is missing from boundary=administrative relations as well, based on discussion in OSM-carto issue #103, and pull #2816.
One of the big issues ‘place keys have, whether on nodes or areas, is that because of the organic, somewhat unstructured what OSM has grown, ‘place=‘ has in principle become a key that represents elements of two different kinds of maps. Let me explain:
Among possibly even more things, ‘place’ on nodes is believed to be used as a navigation/waypoint and label feature (primarily as an element of a navigation map), and ‘place=‘ on areas is believed to be used as an element of a *geographic* map (this is a feature that exists in this location with these boundaries). To my knowledge, there is no documented OSM map element whose primary purpose is ONLY as a navigational waypoint, and I think it fundamentally prevents separating off the two distinct purposes.
Therefore, I propose taking the proposed new relation of ‘type=place’ and making the following changes:
- Remove the ‘place_centre’ role from the proposal. What ‘the centre of a place’ is can be confusing, and may be referring to an editor’s estimation of geographic center (open to interpretation), label (appropriate place for a static node to be placed, and already exists in any case), or waypoint (what is estimated to be the best coordinate node to be navigated to when you ask to be navigated to a given ‘place’.
- Create a ‘waypoint’ role in the proposal, whose stated explicit purpose is to be a navigation endpoint when a data consumer requests navigation to a relation of type ‘place’. It would also be useful for boundaries of type ‘administrative’. It’s up to a navigation engine to decide what to do if a ‘waypoint’ relation member doesn’t exist; navigate to an ‘admin_centre’, ‘label’, or simply calculate a “center” of the area, but the point is, it would exist for that purpose.
The advantage of calling it a ‘waypoint’ is that there is no ambiguity as to the purpose of the node. How or if it’s rendered by maps, or what other tags it should also have on it is a point of discussion, but I feel confident that the ‘waypoint’ relation member role itself is needed, and is a hole in OSM’s implementation of navigable places.