Proposal talk: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 have 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 [[1]comcommaker] aggregate boundaries to create new entities without need of relation knowledge.

So voting against your proposal in advance. --Nospam2005 (talk) 21:14, 23 June 2017 (UTC)

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.

Skybunny (talk) 15:35, 12 September 2017 (UTC)

Skybunny, I've indented your code in order to see better what is your contribution.

"based on discussion in OSM-carto issue #103, and pull #2816." I was reading those threads and when I saw the proposal of reusing the boundary model, I thought fine, I'll go that path. As it was not working (without a place node used as label) I came to the link to see what I made wrong. Then I saw it was a proposal I made long time ago ;-).

But I see an issue to name the member waypoint: it's the place where the label would be put too, so it's not valid for navigation engines. IMHO, we can also keep label but make clear that it's also used as waypoint for navigation system. Or the other way round you'll object. Right, just label=* already exists. reference_point=* would be IMHO option more neutral.

I was not about to create a new type of relation, just use the relation type=boundary but with boundary=place. BTW I see 6.500 usage of boundary=lot which is pretty much the kind of places I was thinking about.

--Nospam2005 (talk) 20:59, 23 September 2019 (UTC)

"I do have what I hope is some constructive criticism of this proposal"

I forgot to answer that point: of course I see it as constructive, and I see my proposal as constructive as well as I propose to replace the proposal by another one, mostly simplify the description with analogy to the boundary=administrative model and focus on scenario A. Using relations in general, reduced to the contour as polygon makes sense only if the contour is not partially shared with another such place. And reduced to the label/waypoint/reference_point if it has fuzzy limits.

It's more or less giving a guide (as already implemented except reference_point=*) and compatible with existing usage but answering the same need.

Example: I've implemented 2 contiguous places that way: [Prat] and [Jardins de Vitalis]. As you see they are properly displayed on the default map. With reference_point=*, they would also I guess but I don't want to introduce into the database before approval. --Nospam2005 (talk) 20:30, 3 October 2019 (UTC)

"Centre nodes"

"If a mapper maps a place=* feature as area in order to detail the extent of a settlement the information about a centre is lost." Some people appears to be going and on about this. In my 9 years as contributor I've been looking at hundreds of (primarily) smaller settlements (hamlets, villages & towns) and in my experience "the information about a centre" for the vast majority of these is no real loss. I'm seeing lots of place nodes placed in parks, parking lots, fields or other open areas (this of course makes them easier to spot). Imho, a "centre point" calculated from an area (when needed) would be every bit as good. --Hjart (talk) 18:11, 8 January 2018 (UTC)

Thanks for these insights!--Jojo4u (talk) 18:11, 4 October 2019 (UTC)

Right... and wrong. Wrong because places as areas are not displayed with the default style. So the information is made invisible and therefore lost for most end users (except if they are using Nominatim) but no real information is lost. See the previous section for a possible solution ;-) more cleary presented by Skybunny in his proposal). So you're right in the sense that often there is no real loss (except if we decide that this point should be the default place a navigation system should drive you too - which what Skybunny proposes. --Nospam2005 (talk) 19:05, 4 October 2019 (UTC)