Talk:Key:place

From OpenStreetMap Wiki
Jump to: navigation, search

Commas

Are commas in values ok or is it better to use another deliniator? Blackadder 17:36, 17 Mar 2006 (UTC)

Yeah I want to know this too. eg. name=Australia place=continent, country, island. Justcameron 18:04, 22 September 2007 (BST)
Use semicolons (";") - see FAQ#What_shall_I_do_for_roads_that_have_multiple_values_for_a_tag.3F --axk 14:07, 26 January 2009 (UTC)
I'm replying to this for completeness sake, and stating the up-to-date advice people would (I think) generaly give these days, but the question is very old (TODO: archive). The reply:
See Semi-colon value separator. However "It is particularly important to (wherever reasonably possible) avoid ';' separated values in more important "top-level" tags". What is the use case for multiple values in the place key? When classifying a place, it's probably more useful to pick one or the other value.
-- Harry Wood (talk) 11:03, 18 January 2017 (UTC)

Transport restrictions?

Why are the examples for place_name, place_numbers and postal_code headed by "Transport mode restrictions"? I do not understand the connection.
RalfZ 14:03, 21 February 2007 (UTC)

Looks like that was fixed at some point in the decade since you posted that comment! (TODO: archive) -- Harry Wood (talk) 10:57, 18 January 2017 (UTC)

Distinctions

Where did the figures to distinguish between village, town and city come from? If memory serves, in 'A' level geography I was taught that a village is anything with fewer than 5,000 residents. Is there a definitive source for this that's international? The city value could also be contentions, at least in the UK. For example Reading has a population of well over 100,000 but it remains the UK's largest town rather than city. TomChance 18:52, 9 October 2006 (BST)

I found the number of 100.000 and higher for cities on the map features page. I took the liberty of coming up with the number of 10.000 for discriminating between towns and villages as I think it is necessary to give a guideline for people tagging populated areas.
As long as there is no fixed rule, I hope those numbers are better than nothing.
I would like to have an easy rule rather than a political correct definition with lots of exceptions.
RalfZ 19:29, 9 October 2006 (BST)
Could the City-hamlet tags be better defined? Currently a hamlet could be a place with 9,998 people living there. A overall world wide definition needs to be created, but in the UK the following could be said. (please correct if wrong).
  • City= Population over about 200,000, or a place marked as a city (usually because of a Cathedral).
  • Town= A place with a population between about 5000 and 199,999 people, or again anywhere marked as a town. (figures based on Uk largest towns, which are places like Reading and Northampton)
  • Village= A place with a population between about 200 and 4,999 people. Villages lack a market, or key features such as town halls/a mayor.
  • Hamlet, A place that has under 200 people. Contains no shops, and usually no religious building. (Based on a few figures I know of. a Wikipedia example is 'Little London, Buckinghamshire with 70 houses, so population est would be 175ish.)
I'm asking this as I have seen many large villages in central norfolk that were tagged as hamlets (Yaxham for example, which has a population of around 700 I think, so is a moderately sized village), and I would definitely disagree, but there is no osm guidelines that I can base a decision to change the tags on. If these are correct, then I need to change many villages to hamlets. Although there are always exceptions to the rules (city - St.Davids, Town - Llanwrtyd Wells, Village - Ashington for example), but I think the majority could be defined a bit better. Please add comments about how other countries would define them.
There is also the point that unlike a village town and city, In the UK a hamlet isn't different apart from in size to a village. So its a size thing not a political thing. Is this different elsewhere?. On this principle why not have tags for large villages and small villages, as there is a great difference. The lack of shops in small ones is an important thing that should be visible in a map. Ben.14:17, 23rd December 2006 (UTC)
In my opinion, city-town-village is not enough choice. Cities with very different populations are tagged the same. Something like this would make the places more useful:
  • place=vlcity = a city with population over 1,000,000
  • place=lcity = a city with population between 500,000 and 999,999
  • place=city = a city with population between 100,000 and 499,999
  • place=ltown = a city/town with population between 50,000 and 99,999
  • place=town = a town with population between 10,000 and 49,999
  • place=village = a village/town with population under 10,000
Of course, that would be just a rule of thumb, as there are countries that have different kinds of municipalities. For an example, there are 415 municipalities in Finland, of which 113 are considered cities. So, in the scheme I suggested, the smallest city, Kalajoki with population 1,473 would probably be tagged town, while the largest non-city, Nurmijärvi with population 38,938 would be tagged village. Galactic 14:43, 20th December 2008 (UTC)

In uk, australia and new zealand, the size of the place is irrelevant - the status is decided by central government. I would guess the same is true in most western countries. Myfanwy 22:49, 3 April 2009 (UTC)

Oh yes: [1]. To be honest, I like a functional definition, like Wikipedia's "Cities generally have advanced systems for sanitation, utilities, land usage, housing, and transportation and more[2]" better than decree-based approaches, since neither population nor decree alone always imply the above. Still, the current approach seems to be to choose either the population-based or the decree-based style on a country-by-country basis: so for the UK at least the established usage seems to be to follow the Royal charters granting city status. --achadwick 11:52, 16 November 2009 (UTC)

As for rendering concerns: just use population=* to the nearest 1000-5000 or so, and have the renderers determine whether or not a label is displayed from that. Populations grow and shrink, so it might be a good idea to note when the population data was updated. --achadwick 11:52, 16 November 2009 (UTC)

Howto

How does this work? Should I add as many place tags as possible to every node in city or do I only add it to central node in, e.g. the middle of the city? I'm mapping a city with a clear ringway around it, should I add place=city, place_name=CityName, postal_code=999 to ALL nodes, segments and ways here? --Cimm 7 Nov 2006

just central node. Ojw 14:51, 7 November 2006 (UTC)
Thanks, so which is the central node? The center of the city, the town hall, the main square, some random node in the center? How do you know where the boundaries of this administrative region are, draw an area and assign some tags to it? The central node does not give any information on these boundaries. --Cimm 7 Nov 2006
Make a guess based on local knowledge for the "center" of town. Placing the marker node off-center in a less-cluttered portion of the map should be acceptable too. Rw 17:50, 7 November 2006 (UTC)
"Which is the central node?" seems like a strange question. Don't just find some existing node and add a place=city tag to it. Generally you should be creating a new node specially for the purpose of being the central place node. It is just "some random node in the center" (and only vaguely placed in the centre, as we've said) but the node shouldn't be doing any other job. If the place=city node is also a highway=bus_stop, that might work in the renderers (not sure) but it'll be confusing, difficult to find while editing, and sementically nonesensical. -- Harry Wood 12:19, 9 May 2008 (UTC)

Difference between name and place_name

Could someone try to explain (maybe with examples) the difference between name and place_name?
I typically mark a town center with a separate node marking the center and having the tags place=town and name=townname. What information should go into the place_name tag?
RalfZ 14:03, 21 February 2007 (UTC)

You are doing it correctly.
The idea seems to be that place_name never goes on a node. It's for a way which loops around the extents of the city/village.
I'm not sure why we should use place_name and not name. I guess it is to avoid clashes with names of roads, if you're sharing the same way which already has a road name.
All seems a bit clumsy to me. Personally I've never created a way around the extents of a place, and I'm not sure how many places have them or how widely accepted this is.
It's quite common, there are more than 3000 place tags applied on ways in planet.osm. I have no idea why place_name should be used instead of name. Actually name is used much more often than place_name for ways around extends of place.
You can get all place_name tags with xapi - http://www.informationfreeway.org/api/0.5/way[place_name] --Jttt 21:40, 29 May 2008 (UTC)
I also notice that FAQ#What makes a road belong to a city? says "There should be a closed way marking the extent of the city with a "place"- and a "name"- tag" ...so that's inconsistent then. --Harry Wood 12:46, 9 May 2008 (UTC)
I've been playing around with this recently. Mapnik renders the name around the edge of a place=foo area, and this does not happen when it's switched to place_name=foo. So place_name it is for me. I've not seen any evidence that the gazetteer actually does anything with area-place, but it's enough for me to be working according to the most canonical docs for this (the main page for these comments here). I've corrected the inconsistency on the other page. --achadwick 13:18, 6 August 2008 (UTC)
I also notice that Mumbai has a place=city,name=Mumbai loop around the whole city (coastline). This is AND data imported for india. In Osmarender this results in rendering of a name label (so much for 'place_name'!). However the central place node also gets rendered, hence two Mumbai labels.
I find the Key:boundary instructions to be more well thought through, and largely serving the same purpose.
-- Harry Wood 12:46, 9 May 2008 (UTC)

Importance

Is there a way of specifying importance of a place, as a lot of places in Scotland are only villages, but are quite important ones. Examples are Mallaig or Aviemore. Bruce89 01:29, 1 January 2008 (UTC)

Suggestion on changes on place tag

I feel the place tag is a bit too narrow in its definition. Villages and towns are not the only places one would like to tag. What about other features that doesn't already have a well defined border, like a bay, a mountain range, or a part of a city where suburb isn't really the correct term for example.

My suggestion is:

  • "place" tag have values like "urban" for cities and villages, "geographic" for mountain ranges, and "water" for features at sea or in a lake (those labels would probably be rendered different than land features, like in a blue color). Feel free to find other or better values.
  • to differentiate between places of different size and/or importance a "place_level" key is introduced. Values could range from 1-10 or probably more. A recommendation for what levels to use should be defined but not too narrow, there should be room for in-betweens/local differences. (See boundary)
  • A place could be an area!! A mountain range is not something that have a distinct border, but it's definitely not a point. One should be able to make an approximate outline of the feature that is to be named. The renderer should then be able to write a name label on several tiles if the feature covers several tiles at some zoom level.
  • place_name should go away. There is already a name tag.

That's probably not all, but at least a start --Bengibollen 17:04, 17 January 2008 (UTC)

I totally agree with the second point - only three levels is not enough (city, town, village) - a few more levels would be useful and it would probably make it easier too to draw those on a map. I was looking at a map of Poland and according to OSM criteria a place with 8000 inhabitants is mapped as 'village' although it has an official status of 'town' and is much bigger than a village of 500 people. Mfloryan 15:40, 9 September 2008 (UTC)

The suburb value is also rather strange. We need something better for urban areas. Many urban areas are not surburbs, they are 'urbs'! I suggest place="district" and place="neighbourhood" would be more appropriate, although of course district is contentious. These would relate to boundary levels 9 and 10 probably, but without having actually know the exact boundary jamesks 14 Jan 2009 (UTC)

There shouldn't be made new values for the place tag. They're already meaningless anyway in 90% of the world, or they're highly ambiguous where the (translated) names like "city" or "district" have special meaning, but which have to be ignored anyway, as the value for the place tag is now based on some arbitrary limits of the population in that place, and not on definitions. Hence we need a complete overhaul of the place concept, not some extra values which will make it more of a mess. --Eimai 15:32, 14 January 2009 (UTC)

City contour

I understand one is supposed to draw the contour of a city, region, etc. for the roads/places inside to be attached to a city. This means I have two unanswered questions.

  • Should roads be split at the border even if they're actually the same (same name, etc) or is the attachment automatic?
  • How do I deal with a road (without central separation) which has one side part of a city while the other side is part of another city. To make it clear, at the intersection where the road begins, on one side of the road there's a sign stating the road's name and the name of the first city. Across the street is another sign with the same road name but with a different city name.

Pov 23:14, 19 September 2008 (UTC)

Tagging areas

Currently the commonly used way to tag the area of an place is to draw a way, tag it with place="XYZ" and no name and then add a node with place="XYZ" and name="ABC".

However I think the best solution for tagging areas would be to just draw a way around the perimeter of the place and tag it with both place="XYZ", name="ABC". If more controll about the label placement is needed a Label-Relation (supported by at least osmarender) can be used. This is how we do it for other features and I see no reason to do it differently here. Also the data is much easier to process this way.

  • Does this mean we should have the same information twice ? So a village would get a node (with place='village' and name ='xyz') and additional an area with the same (so place='village' and name = 'xyz' and NOT using place_name)
  • I am refining an area where all the villages are tagged as nodes already (probably from a mass import). I want to add know the areas for the villages. Should I now
    • add an area arround the village (place=village, name ="xyz") and keep the original node or
    • replace the node, so creating an area and moving the additional information (poplulation ...) from the node to the area ?
All you said makes sense to me. place_name is some sort of hugly work-around for name colision, having duplicates with a node and an area looks bad to me, and if a renderer problem exist use a tag/relation/label dedicated for rendering problem and don't mix place's nodes beeing at the same time a place and a label. sletuffe 23:04, 8 November 2009 (UTC)

How To Tag

The main page needs a "how to tag" section showing in part how to add the central/labelling place node to a place area, and ideally done in a graphical and unambiguous fashion. The current information doesn't really explain how the two bits should be made to 'match', as it were: all there is is a FAQ entry and some discussion on the talk page. Let's add something better! --achadwick 22:13, 13 November 2009 (UTC)

How much needs to match?

One question that falls out of thinking about this stuff: if you have a place node which uses is_in, and which is defined by both a node and an area, what should we be telling users to do? possibilities:

  1. tag the node with is_in, but not the area;
  2. tag the area with is_in, but not the node;
  3. YOU MUST TAG BOTH FULLY, AND MAKE EVERYTHING MATCH GODDAMNIT; or
  4. any of the above, and renderers should ensure consistent rendering for themselves.

Myself, I prefer option 4. I guess the one real invariant with this clunky old schema is that if you're doing the node+area trick, you must:

  • make the area's place_name value match the node's name value, and
  • make the area's place value match the node's value for the place key.

you probably need both in case anyone's crazy enough to use nesting or overlapping suburbs, for example. But what are people doing out there in the wider world? --achadwick 22:13, 13 November 2009 (UTC)

5 tag the area without is_in and not the node if you know the city extents, else just tag it as a node.
Also get rid of the place_name VS name confusion, a place having a name is of course the place's name, what else could it be ?

sletuffe 13:48, 14 November 2009 (UTC)

The "city" distinction: recent wording disagreement

User:Wynndale seems to want to change my (admittedly rather horrible and fudged during tidying and prettification) wording:

In some countries, these are defined by charter or other governmental designation. In most countries, population size should be used: see above.

to:

This tag is used to determine which place names appear on small-scale maps and should be used to ensure that a reasonable and useful selection of places appears on them.

That's a pretty sweeping change! Right now, either population size or governmental decree should be used as the first measure as described in the introductory paragraphs (consult your country's page here on the wiki to see which one is used). Admittedly there are some corner cases: for example, tiny cities-by-decree with low populations and importance. Ely (~15,000), and St David's (<2000) are good examples in the UK. There's an argument to be had, but a fiddly little table cell on the main page is not a place to thrash it out. I've reverted; I may even backpedal and lose the "most". @Wynndale: with your wording it sounds as if you are advising users to tag for the renderer on a case-by-case basis. If you're making an argument about relative importance instead, then you should state that elsewhere rather than in a fiddly little table cell (because it's, er, rather a huge argument).

Let's thrash out the wording here, place the actual classification discussion under #Distinctions above --achadwick 11:33, 16 November 2009 (UTC)

Farm vs. Isolated Dwelling

How exactly does Isolated Dwelling differ from Farm, and how are these exactly different from Hamlet? I am a little confused on separating these. In Norway where I grew up most farms are separately named, so I can understand a separate farm tag for that, and as a group of farms can make up a hamlet, than I guess farm is a finer division. But how does Isolate Dwelling come in here? Is the lonely house far inside the wood a hamlet or an isolated dwelling? I think it can be both. (ok, I disagree that Isolated Dwelling deprecate Farm) --Skippern 01:18, 18 May 2010 (UTC) Isolated dwellings includes farms, but 1) it's not bound to agricultural use (contrary to farm), and 2) is more precise, as "farm" seems to refer only to the building, or also to the fields nearby, depending on sources. So I agree to deprecate farm as a value for place. Gall 11:51, 28 May 2010 (UTC)

Place=* world wide default unification

Yet another attempt to provide a world wide uniform classification scale of permanently populated places : Proposed_features/world_wide_place_default_standardisation sletuffe 14:20, 27 May 2010 (UTC)

Routing and Places

If you're using simplistic routing using OSM (eg the Garmin map exports, or Skrobbler) "Find Town > Anytown > Go!" will take you to the place node. This may be worth considering when siting the node. --andygates 20:58, 4 December 2010 (UTC)

Name rendering on polygons

The current page claims that the name is rendered in the center of the polygon, if the polygon is tagged as place=*. And that using place_name is the way to avoid having the name rendered. In my experience, that's inaccurate. Mapnik renders the name along the border, and in a very small font at high zooms, not at all in the style that a point with the same place=* tag would be rendered. Please either show me a permalink to a polygon tagged place=* with name rendered, or fix the page.--Ponzu 08:05, 15 April 2011 (BST)

IMHO, wiki pages describing tags shouldn't propose/try to impose a rendering, at most a small sentence saying "this tag is currently used at render X and Y" whould be enough. sletuffe 13:48, 15 April 2011 (BST)
At the very least proposal authors are encouraged to suggest rendering for new keys/tags. As far as wiki pages for tags, I can see how mentions of rendering can lead to controversy, especially if the stylesheet changes. This page is a good example, since the description of rendering behavior is inaccurate -- no one has disputed my claim yet. Still, there should be a reference of how popular elements are rendered so that those who "tag for the map" (if not "tag for the renderer") have an idea of how tagging decisions affect the map as one of the main products of OSM. Maybe it should be a separate ski page. Maybe there is one?

Place or/and administrative boundary

The city that I'm mapping has both place=suburb and boundary=administrative+admin_level=10 describing identical regions. Which should be used? I've read the wiki and it would seem to me that administrative boundaries are the correct choice here; http://www.openstreetmap.org/browse/relation/1517090 (where one can see "Johanneberg" rendered twice).

I found that place=* does say exactly how it should be done. Not sure how i missed that. --Micket 16:31, 29 May 2011 (BST)

Places and administrative boundaries

In December 2011 I did a major edit pass to this article in which I replaced the table of values in this article with an inclusion of the longer table used on map Features. The Map Features table had a mode extensive set of recommended values which included ones for place=country, place=county, place=state etc. Personally I think that we should guide people to the boundary=administrative for these and over time remove the entries from this table? Any thoughts? PeterIto 09:45, 22 February 2012 (UTC)

place_name usage ?

I am not agreeing with this change, it does not mean the same as before, and I suggest we should discuss it before validating it. And, try to find a consensus on the usage of place_name if we want to change it's meaning and usage. Can you please revert your edit and come talking about it ? sletuffe 20:56, 7 November 2012 (UTC)

I am not clear what the problem is, but do please correct it as you see fit. It wasn't my intention to be controversial. My starting point was removing the reference to the 'Notes' section which doesn't actually exist on the page as per this comment. I couldn't find the 'Notes' section in the history for the page either. PeterIto 21:47, 7 November 2012 (UTC)
That was my addition, but not only because there wasn't a Note, but maybe because that previous "note" was maybe usefull to understand what place_name was for, compared to using name. I'll change the template to return back to the previous sentences. However, it doesn't solve the question of usage of place_name in conjunction, in replacement or in double tagging of name. sletuffe 21:58, 7 November 2012 (UTC)
Let's not have a reference to a note that doesn't exist relating to something that the current authors of this page don't even understand. Far better to either put a clear description about how to use place_name in the description field against the tag says what we do understand and also a comment says 'there is currently no clear understanding of how this tag should be used'. PeterIto 09:39, 8 November 2012 (UTC)
I have no problem to add a quick note like : there is currently no clear understanding of how and when this tag should be used, but I am against, without discussion, to try to solve the ambiguity by changing the current wording. sletuffe 15:54, 8 November 2012 (UTC)

Ok, here is my proposition to simplify the understanding of the place_name=* tag : Proposed_features/drop_recommendation_for_place_name sletuffe 16:18, 8 November 2012 (UTC)

Results of discussions over there, I'm updating the wiki here accordingly. sletuffe 23:19, 10 December 2012 (UTC)

Nodes and areas for settlements

It would probably be useful to talk about clearer guidance on using nodes and areas for settlements. My preference is to always position a node for a settlement at the location that is considered to be the centre of the settlement (the town hall, main square, main church etc etc). To be clear, the node should be position at the centre, and not to one side to support the renderer (which I often see) - the renderer should be able to determine where is the correct place to position the node based on zoom and other circumstances. I also prefer the node to be separate from road network. A router should be able to figure out how to get someone to one of the roads nearest to the node and not require the place node to be a node in the network.

Regarding the boundary of the place. It is certainly also of benefit at times to know the extent of the settlement, however this is often much more subjective that the location of the 'centre. To be clear, this shouldn't be confused with the administrative boundary which is often not completely aligned with the perceived boundary).

By way of example the cetnre of Ipswich, Suffolk is traditionally considered to be the monument in the middle of the corn exchange next to the town hall. The subjective boundary of the town is unambiguous in parts (for example to the south west), however to the east it is extremely unclear whether Kesgrave is part of 'Ipswich' (ie a suburb) or not. If Kesgrave is included then what about Grange Farm and then Marltesham Heath which now form a continuous built-up area. I don't believe that anyone would say that Martlesham Heath was in Ipswich and I suspect that many people in Kesgrave will stick to the historic view that they are separate even if people in the rest of the town would consider them to be part of the town. The administrative boundary incidentally does not include parts of the built-up area to the south west that would definitely treated as being within the subjective boundary of the settlement.

Regarding place names, we need to ensure that we don't get two names rendered on the map. Similarly, we need to avoid having two (or even three) instances of the same place in the gazetteer lookup (ie one with a node, another for the area and another for the admin area.

-- PeterIto 10:31, 8 November 2012 (UTC)

As well as the extends of a settlement, the "center" might not always be observable, but, I also like to, when possible. However, that use isn't what all people do, and the "for the renderer" seams to still be used a lot. About the renderer beeing able to determine the position there are two questions : is it possible, and is it done somewhere ?. IMHO, the answer is "hardly" and "no" respectively. It lead to the idea of a label role (when relations for place areas are used) to help the renderer. (I don't know if it is good or not)
I don't think we need to create a 'label' node. It is perfectly possible to position the node appropriately using software and anyway, the position of the label node would be dependent on font size and zoom. At ITO we sometimes place labels away from the nodes and I saw a nice demonstration of that from Stamen at SOTM USA talking about clever label positioning. PeterIto 21:31, 8 November 2012 (UTC)
A place, as an area, is like you said, not always easy to trace. But there are cases where it can. To me, the place area is the sum of point where the answer to the question "where do you leave ?" would be "X". Which means, that it is of interest, and I like to add that information when possible.
That is fine for places that have clears signs or indicators and I would support their use in those situations. PeterIto 21:31, 8 November 2012 (UTC)
About the : "how do we avoid double rendering, double search finding", I think a good way to do that, in the future is One_feature,_one_OSM_element, the question remains : "how do we get there ?". sletuffe 16:09, 8 November 2012 (UTC)
However.. are we not talking about places potentially having both a boundary and a 'centre' (which may not be at the centroid of the boundary). Possibly we could bind them together with a relation, or possibly the gazetteer should just notice that there is a node contained within an area with the same name and use only the node for the search and the boundary for selecting the view-port. PeterIto 21:31, 8 November 2012 (UTC)

Verifiability of mapping populated places as areas

It seems this page as well as the tag pages for populated places lack any definition on how the area of a city/town/village/hamlet can be delineated making mapping those places as areas non-verifiable. Existing data in the database supports this - there is a fairly wild mixture of place areas representing administrative units, aggregates of urban landuses and other variants. See for example the number of tag combinations for villages with landuse=residential and boundary=administrative here and here. --Imagico (talk) 09:22, 10 September 2017 (UTC)

There are few different properties of areas - probably shape, size, placement and name. While shape and size are only related to areas, placement and name are also properties of nodes, so it would be interesting to ask and compare how verifiable are these properties when dealing with nodes. Kocio (talk) 18:30, 4 November 2017 (UTC)
Do i understand you correctly that you agree that the extent of a populated place is not verifiable but you think this is no problem because there are other things in OSM that are not verifiable either so you think (at least here) the principle of Verifiability should not matter? --Imagico (talk) 19:22, 4 November 2017 (UTC)
I don't know it - it's a question, not a statement. I just want to look at the whole problem what exactly we try to verify here and how to do it. Kocio (talk) 19:42, 4 November 2017 (UTC)
What lacks verifiability is - as explained - delineation of a city/town/village/hamlet - which you need if you want to map it as an area since for that you need to draw the outline of said area. Imagine a mapper in some so far unmapped village - how should this mapper verifiably determine where to draw the outline? --Imagico (talk) 20:42, 4 November 2017 (UTC)
If you assume that populated place is (more or less) where people live, it might be easy: just find the outline of coherent area with buildings, parks, cemeteries and similar objects. I guess such areas are verifiable. That's my first approach to this problem. - Kocio (talk) 21:04, 4 November 2017 (UTC)
That would be incompatible with the idea of Skybunny that the populated place area should match an administrative division and a large part of the data does not match this definition either.
I would also like to remind you that this discussion is not about what you desire mapping of populated places as areas to mean. This is not a proposal for a new tag, this is documentation of an existing tag and its current use. It is highly advisable to take a look at how place=city/town/village/hamlet is used on ways and relations. A mapping rule that conflicts with 2/3 of the features in question simply is not going to work no matter how verifiable it is. --Imagico (talk) 21:39, 4 November 2017 (UTC)
"Good practice" approach is advice what to do when things are general and not obvious, so there might be more than one "good" pattern. I just gave the example which I think is both simple and verifiable. But, as you have noticed, it's just a proof that it's possible to make place area proper citizen of OSM, not the analysis how is it really used. I don't plan to examine our database, improving the definition would be enough for me. - Kocio (talk) 21:56, 4 November 2017 (UTC)
You mostly lost me here with when things are general and not obvious and good pattern. Again the purpose of this discussion is to address the problem that mapping populated places as areas is not verifiable - either by showing that it is (and documenting that) or by documenting in more detail the lack of verifiability in the existing data and clearly discouraging mappers from further mapping things in this non-verifiable form. Creating a new definition without considering if it matches the current use of the tag is not really an option (you would need to create a new tag for that - like place=builtup_area or something like that).
So i would once more call out to anyone who thinks the current practice of mapping populated places as areas is verifiable to explain how this is (and add such explanation to the tag documentation) --Imagico (talk) 22:29, 4 November 2017 (UTC)
Unfortunately I have no solution for your problem (documenting current state). But I think "place" is general tag for a purpose - it's used when we have a name and some node/area, which might be composite and when other options (like single landuse or admin border) might not be suitable or known at a given moment. Therefore I don't like throwing area toponyms off the window and defining new tag instead - it's better to show how to best use such general tag, even case by case. - Kocio (talk) 23:03, 4 November 2017 (UTC)
I'd say it's a best practice to apply additional tags beyond JUST a place tag on a way defined as an area. This will usually mean a boundary=administrative and relation for that tag, or a source tag which indicates the justification for the area as it's drawn. I realize that this isn't specified in this key's page, but it probably should be. (One could make the same argument for a node, too - why 'here' and not 'there'?, but for nodes we do have some good best practices already, like 'a major road interchange' or 'where the town hall is'.
You're right that we don't have that for areas, and probably should. If I was spitballing it, I'd say 'a reference-able administrative area or other mapped shape, such as a census zone, legal description for a boundary', 'extent of a populated place as defined by the mailing address town/city/etc.' of that name, and so on. Skybunny (talk) 18:34, 4 November 2017 (UTC)
As i read your comment apart from the same argument as Kocio (verifiability is not needed because there is other non-verifiable stuff) you say that a populated place as area should be the same geometry as some administrative unit - unless the mapper decides on something different on a per case basis and documents this in a verbal description in the source tag that is not machine readable and cannot be used by data users instead of creating a new tag and documenting it with that description on the wiki as you would normally do if you map something for which no matching tag currently exists.
Regarding the idea that a populated place area should be an administrative division - this definition as explained clashes with current tag use - only about 15k of the 87k place=village mapped as areas are boundary relations. There might be a few more with a second way/relation tagged place=village geometrically identical to the boundary but overall the majority of the populated places mapped as areas do not comply with your definition (although a significant minority does).
Also note that for where i live this would mean http://www.openstreetmap.org/relation/62768 should be tagged place=city (and similarly with many other German cities/towns/villages). You will have a hard time convincing people of that. --Imagico (talk) 19:22, 4 November 2017 (UTC)
Since both of you hinted that the coordinates of populated place nodes might also not be verifiable - i considered arguing that point but i think this would side track the discussion here which is about the verifiability of populated place areas and not of nodes. If you want to argue that populated place as nodes are non-verifiable that should be a separate discussion. --Imagico (talk) 19:22, 4 November 2017 (UTC)
Chopping complicated problems into parts is a valid procedure and can help find the solution, but it can be too narrow and not optimal. Searching analogies is equally valid way and might lead to better results. I propose to think how we can verify place nodes and check if this can be extended into areas somehow.
I like the suggestion that there might be "good practices" for nodes - so we can have some other for areas too. We can decide that good practice for populated area is tagging - for example - coherent sum of residential + industrial + leisure areas. This can be verified and if we agree on such practice, it wouldn't be hard to tag your city. - Kocio (talk) 20:19, 4 November 2017 (UTC)

I've just learned that my idea of tagging places as areas, which can be verified, is actually observable in the wild: Rødding has been mapped this way a year ago. This is a case of multiple landuses mixed in a coherent area. It's also a proof that sometimes it's easier to show the outline than find a center (one can say that it's a point near the crossing of the main roads, of course, but the outline is just more intuitive here). --Kocio (talk) 16:29, 18 November 2017 (UTC)

I see nothing in your statement that indicates a new perspective compared to what has been discussed above and what is now also explained on the key page - that the outline of populated places is usually not verifiable and existing mapping follows very different ideas of the definition of the extent of such a place. Even if there are individual places with a verifiable outline that does not proof outlines are usually verifiable (see here). The shown example of Rødding tries to follow the second definition (aggregate of urban landcovers) - however even within that definition it is a good example for a lack of verifiability - why for example are https://www.openstreetmap.org/way/229377907 and https://www.openstreetmap.org/way/426951566 included but not https://www.openstreetmap.org/way/229377915, https://www.openstreetmap.org/way/338039318 and https://www.openstreetmap.org/way/97588405? why are https://www.openstreetmap.org/way/229377965 and https://www.openstreetmap.org/way/229377964 partly included and what is the significance of the location where they are split? And beyond that of course how does a mapper know that this is what is to be tagged place=village and not the boundary of Rødding Sogn (which apparently is currently not mapped in OSM as a boundary relation)?
If you want to map populated places as areas you need (a) a verifiable definition of the geometry of this area and (b) a different tag because place=village etc. are - as demonstrated and documented - already used on areas for very different and contradicting ideas.
The place node for Rødding most mappers would probably place near https://www.openstreetmap.org/node/263488616 (main street crossing, area of highest building density). --Imagico (talk) 18:59, 18 November 2017 (UTC)
Of course it's not a new perspective - it's just an example of what I said before.
And when you say "probably" - how could you verify this placement so nobody could ask similar questions about the node location?
My point is exactly like that: if you claim that outlines are not OK, because they are not verifiable, and the nodes are OK instead - how do you (and in general - we as mappers) actually verify it? What is the node location definition then (other than some good practices, which you just mentioned)? --Kocio (talk) 19:12, 18 November 2017 (UTC)
I think we have had this discussion above already - The verifiability of mapping populated places as nodes should be a separate topic. Lets not mix these two questions. There are certainly populated places where you cannot find a well defined center but for the vast majority of settlements you can. We have a consistent documentation how mappers can determine the place center and existing data indicates these rules are used consistently as well. Making a verifiability test (like tasking a hundred mappers independently to place the node for a settlement and see if the positions converge to a single center) would for Rødding most certainly yield a positive result. This contrasts sharply with the situation for areas - which is the topic here.
This does not mean there is no room for improvement in case of place nodes - but as said: Different topic, to be discussed separately IMO. --Imagico (talk) 19:52, 18 November 2017 (UTC)
OK, I started a new subject about it to make it easier to discuss.
However I feel that it's not that different - from your suggestions above I see that "verifiable" may mean "many people feel the same" (not a sharp contrast for me) and that you accept good practices for nodes ("The simplest and most widespread method to map most place types is to position a node at the recognized centre of the place, which should be location of the town hall, central square, or similar for a populated place." is not strict definition, just a guideline) and I suggest to do the same for outlines.
The only big difference is a practice - you claim that most of the time people make good choices with nodes and bad choices with outlines. But we're talking about definition here - we also set the standards in wiki, not only discover common rules. --Kocio (talk) 20:23, 18 November 2017 (UTC)
Kocio - this is getting a bit unnerving - the key page explains there are at least three different contradicting ideas mappers follow when they map populated places as areas and i explained this again above. No matter if you abide by the concept of verifiability or not - you will not be able to find a definition or mapping guideline that is compatible with three contradicting ideas of the meaning of a populated place outline at the same time.
So once more: If you have a concept for mapping populated places as areas you want to see used you should create a new tag because place=city/town/village/hamlet is burnt for tagging areas because mappers already use it with very widely varying contradicting meanings. You cannot just change the definition and hope the data magically adjusts to that. --Imagico (talk) 21:04, 18 November 2017 (UTC)
I prefer to talk when the opponent can accept that I may simply not share his vision at all (in the worst case). Repeating does not make anything right, especially when you claim the things I don't even mean. For example "you will not be able to find a definition or mapping guideline that is compatible with three contradicting ideas" is a straw man argument. Why do you think I want this is beyond me, but please make less assumptions to avoid the false ones and being upset because of them.
I see nothing magical in making better definition. People will tag most of the things not looking at the wiki anyway (probably just using a name in the editor), but when they come here, they expect to find what's recommended. Do you agree? We don't have to collect all the uses, no matter how contradictory, and call it "a definition". We might recommend just one (or more) specific recipes and reject others as popular but discouraged. What do you think is wrong with that? --Kocio (talk) 22:43, 18 November 2017 (UTC)
The purpose of the tag documentation on the wiki is to document current use of the tag, not to document subjective desires what a tag should mean. If you want to deprecate uses other than a certain form of aggregated urban landuses you have in mind (which i still have no idea how you want to define in a verifiable way - but that's a different story) you can try to find a consensus in the community for that but it seems clear to me that there are people in support for the idea of using administrative boundaries (like Skybunny above) and the tags are in active use in that form so you probably need to create a proposal and try to lobby for support for that. --Imagico (talk) 23:48, 18 November 2017 (UTC)
"The purpose of the tag documentation on the wiki is to document current use of the tag, not to document subjective desires what a tag should mean." - that's not how I feel about the main purpose of tag documentation. Current use might be flawed in many ways (including popular "tagging for rendering" or problems with meaning of words, like "boutique") and that's not more objective. It's good to let users know about the state of things, but usage analysis is just a tool - IMO the most important thing is to provide users some guidance. That is the main difference between us here, I guess.
However I fully agree with you that changing documentation requires consensus what we want the definition to say. If I feel it's important enough for me to make this definition better, I will of course use this way. --Kocio (talk) 00:28, 19 November 2017 (UTC)
Just to be clear - the idea that the main purpose of tag documentation on the wiki is documentation of current use is not just my idea, it is fairly fundamental to OSM, following from Good Practice and Any tags you like. It also ensures a minimum of conflicts when editing the wiki since de facto use of tags can be demonstrated while supposed use of tag depends on your point of view. And it helps avoiding misuse of tags like "tagging for rendering" which is by definition use of tags in contradiction to their established and documented purpose.
Interestingly one of the main reasons for this mess with populated place areas is that those people who originally started using these tags on areas with various different meanings did not properly document their uses. Both the verifiability problems and the conflicting interpretations could have been avoided if these had been documented and discussed early on. --Imagico (talk) 10:29, 19 November 2017 (UTC)
It looks to me like an interesting problem on its own, however really big and even if we took a long journey up to this point, I'm probably not able to look even deeper. There are some problems that pop up in my head now and make me curious, for example:
- documenting is easy when there's a single, easy to follow pattern, but that might not be the case - just documenting a mess is not the final goal of wiki page IMO; I think the guidelines were made with simple assumption that usage will be clear and not diverge too much
- "any tag you like" should probably not mean that your choice is always right and usage might not be the key to notice it
- now I understand why do you think creating another tag is the way to go when the tag usage is broken, but I think fixing might be better because we have limited possibilities of naming things in a meaningful way (like: shop=yes), it's also better if naming scheme is consistent between tags
- the project is mature enough and still growing, which means that some initial rules might need reviewing (and I know that it's really scary meta-problem...)
--Kocio (talk) 02:06, 20 November 2017 (UTC)

Populated places as nodes - definition and verifiability

Currently the wiki page says:

"Populated places (in particular place=city, place=town, place=village, place=hamlet and place=isolated_dwelling) are usually mapped as nodes since in most cases they have a well defined centre but not a verifiable outline."

It sounds for me like a hidden assumption that their location is pretty verifiable.

My questions are:

1. What does it mean "well defined centre" (how do we define it?)?

2. How exactly could we/do we verify node location in such cases?

--Kocio (talk) 20:09, 18 November 2017 (UTC)

1. "well defined centre" essentially means verifiable center. What the center is understood to be is explained on the key page: position a node at the recognized centre of the place, which should be location of the town hall, central square, or similar for a populated place. The individual tag pages have their own description - like for place=village: at the center of the village, like the central square, a central administrative or religious building or a central road junction
2. That seems to be a more general question regarding the concept of verifiability overall (which i think is explained fairly well on that page). I already explained above a possible hypothetical test for verifiability of node locations (asking a hundred people to specify a position and see if it converges).
--Imagico (talk) 20:45, 18 November 2017 (UTC)