Proposal talk:Urban settlements

place_area

What's about:

• place_area=<name of the place>

or

• place_area=yes
• name=<name of the place>

or

• place_area=<type of place>
• name=<name of the place>

where <type of place>=city/town/village... So it is immediately clear to everybody that it refers to an area and that it is related to the place tag.--Viking81 20:59, 12 October 2012 (BST)

place-label for the place-tags on nodes

IMHO a place is never a single point. I'd suggest to change the tagging of place-nodes to another tag and create a relation between these nodes and the place-area. I'd stick to keeping place=* for place areas and use the new invention for the nodes (if there is consensus to keep the nodes). The proposed settlement tag doesn't make much sense to me, as places are not only settlements but also parts of settlements, and also because it is in my understanding exactly the meaning of the place-tag what is described (if I got the proposal right). --Dieterdreist 20:43, 28 October 2012 (UTC)

place=* on an area is fine

The place=* tag on an area is allready used like 200k times in the db, I think it is fine to continue this way. You say that Tagging both would be wrong with two valid arguments. Well yes, then just don't tag both ;-). It is recomended practice in OSM to have one object in the DB = one thing in reality. I think this is good practice, why not do that for places as well ? The quick answers might be :

• Map XXX is not displaying places as areas, well, maybe, but that is not a problem in the data but in this renderer.
• But places are too important, people will continue tagging both until all maps display them as areas. Maybe, but renderer won't switch to areas because it will display twice the name, so they choose to only render names on nodes, but then no one wants to only tag on areas : chicken and egg problem.

Note that I don't think using a 2nd tag will change anything, it will either be ignored : no gain, or displayed : double displaying of names again, double searching in nominatim. sletuffe 00:26, 29 October 2012 (UTC)

Not really. Map XXX (Mapnik's rendering in osm.org ;-) ) is not displaying areas tagged as place=*, i.e., it's not writing the name (see for example Borgo d'Ale). My solution (separating place and extension, or alternatively place and center location) would allow renderers to select, for example, place=* nodes to draw the name, and settlement=* to draw a shaded area that represents the extension. --SimoneSVC 09:49, 29 October 2012 (UTC)

Then we agree that the "standard map" at www.osm.org (old name : mapnik) does not help tagging correctly by not showing names of areas. For you 2nd argument, which resume to : "How to know where to display the name ?". Even if that is rendering related, it has been said that there are no good way to automatically find where to display a name, and I agree with that. Is the solution then to duplicate the place tag ? Maybe not, what we need is a "renderer tag", something like Relations/Proposed/Label for relation : create a node, with no tags at all (or the name, as duplicate) and add it to the area relation, with role "label". sletuffe 12:58, 29 October 2012 (UTC)

I agree that place=* should be left as it is (either area or a node in the center of the place), the renderers should be fixed if necessary. What we need is the possibility to add information about the position of the centre when the place is entered as an area. To this purpose, a node could be placed at the position known as the centre of the place, and a relation created which links the area and the centre. It's the same concept as the label tagging suggested above, but it wouldn't be tagging for the renderer, just adding factual information. --Kaitu 13:15, 29 October 2012 (UTC)

I disagree, there isn't a way to fix renderers because datas aren't homogeneus. The use of place=* now is ambiguous and the result is that some places are tagged on nodes, some on areas and some on boths. Renderers and search engines mess up, they don't know if to display nodes or areas and if they display both we have duplicated values for the same place. Ultimately Simone's proposal is the simplest way to solve this problem efficiently. --Viking81 23:07, 29 October 2012 (UTC)

What about the old "place_name=*" ?

See Key:place. You reinvent the wheel. --Pieren 11:10, 29 October 2012 (UTC)

The place_name=* tag has about the same goal, but I think it is bad practice. name=* is a good tag to record the... name, why try to have a new name tag ? If someone wants to only use the POI's name, then he can just discard the area and keep the node, no need to create a 2nd name tag. sletuffe 12:52, 29 October 2012 (UTC)

I think that place_name=* is not clear, we need a tag that applies only to areas and that it is easy to understand for new mappers, like place_area=*.
place=* or place_name=* on areas should both become deprecated. --Viking81 11:52, 7 November 2012 (UTC)

Currently, we have 2.461.857 place=* and 35.185 place_name=* in OSM. You cannot seriously suggest to deprecate these old and widely used tags. --Pieren 12:11, 7 November 2012 (UTC)

He said "on areas only". And the current count is roughly 220k objects tagged with place=* on what seams to be an area (a way or a relation). But still, I'll vote against deprecating place tags on area. sletuffe 13:05, 7 November 2012 (UTC)

Ok, there are thousands and thousands of areas tagged with place=* or place_name=*, but this doesn't mean that it's the best way of tagging: the double tag on area and node objectively creates confusion and disruptions. Changing all those tags on areas may require 10 years (or few minutes if someone will write a script to do that), but if it produces benefits, we should consider that option. --Viking81 18:10, 7 November 2012 (UTC)

I totally agree with you about changing a bad tagging. But I don't think the current proposal produces enough benefits to justify a change. I'll also be totally against runing a bot, and it might take more than 10 years "as is" because I'll keep adding place=* on areas. sletuffe 18:51, 7 November 2012 (UTC)