Talk:Key:place

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)

We've been discussing this in Talk:Tag:place=hamlet#Hamlet_vs_Village and we think the best criteria is a classification by place features, as population is reflected in another tag and thus would be redundant. Population only needs to be in the right range:

Is it inhabited?

No -> place=locality

Yes -> Is it more than 2 households?

No -> place=isolated_dwelling

Yes -> Does it have a amenity=place_of_worship, festivity grounds or some kind of reunion site?

No -> place=hamlet

Yes -> Does it reach 100 inhabitants?

No -> place=hamlet

Yes -> Does it have all basic services like amenity=school, amenity=clinic, amenity=marketplace, shop=supermarket, amenity=bank and amenity=police?

No -> place=village

Yes -> Does it reach 1,000 inhabitants?

No -> place=village

Yes -> Does it have mayor services like amenity=university, amenity=hospital, tourism=museum, amenity=theatre, amenity=courthouse, amenity=fire_station, amenity=library and office=government?

No -> place=town

Yes -> Does it reach 10,000 inhabitants?

No -> place=town

Yes -> place=city

--Iagocasabiell (talk) 01:31, 5 September 2019 (UTC)

Some place=city, generally in remote areas, have as few as population=10,000 but most are over 20k; between 10 and 20k most settlements are still tagged as towns. Also, some places use a higher cut-off than 1000 for towns, sometimes as high as 5000 or 10,000; though there are certainly some towns with population = 1000 to 2000, in many places the majority of settlements of this size are tagged as place=village. See discussion at Talk:Tag:place=city and Talk:Tag:place=town --Jeisenbe (talk) 01:54, 5 September 2019 (UTC)

I generated a formal proposal for the classification criteria here: Proposed_features/Populated_settlements_classification --Iagocasabiell (talk) 01:48, 7 September 2019 (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:

tag the node with is_in, but not the area;
tag the area with is_in, but not the node;
YOU MUST TAG BOTH FULLY, AND MAKE EVERYTHING MATCH GODDAMNIT; or
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)

I agree, there is no point in duplicating administrative entities with place values. Well, maybe besides preliminary mapping (adding rough data as long as you are not able to actually draw a boundary). --Dieterdreist (talk) 23:07, 5 August 2020 (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)

Hi. I mapped the outline of Rødding (as well as pretty much everything else in it + lots of other urban areas, roads and countless other features all over Denmark). I came across this page yesterday and felt a lot like making it a bit less skewed towards place nodes and only discovered this discussion afterwards. Sorry about that. Anyway, if you are going to nitpick about my choices for the outline for the village, we can definitely nitpick about any choice for a center node location too. I did it partly as an experiment, but while I recognize that it's never going to be absolutely "perfect", I'm still actually pretty satisfied with it (which I wasn't while the village was still only represented by a single node, as I never felt that that did the village any justice). "Rødding Sogn" is the local parish and is really only interesting if you are into religious matters. It's quite a different entity from the village.

Also, at least for Denmark, I disagree with the above quote from the wiki. For the majority of danish urban areas you'd be hard pressed to find a centre more verifiable than the outline. For lots of them the best you can do is "place it somewhere in the middle".

--Hjart (talk) 01:08, 13 December 2017 (UTC)

I have no problem with you mapping Rødding the way you did but this does not make it a verifiable mapping (see the ambiguities mentioned above) and especially it does not change anything about the different interpretations of the meaning of the place area outline as described on the wiki. If in Denmark you consistently map all place areas according to the 'aggregate of urban landuses' interpretation that is something worth mentioning but that would be specific to Denmark and is not the case elsewhere as you can clearly see in the data.

It should also be mentioned that the 'aggregate of urban landuses' interpretation can be inferred from the data with node based mapping in a case like Rødding without problems. But it does not work the other way round - you cannot generally infer the functional center of a place from the outline of the aggregate of urban landuses belonging to it. So node based mapping adds important information, area mapping according to the 'aggregate of urban landuses' interpretation does not.

And just to make this clear - verifiability of the location of a node does not mean 'can be specified with zero tolerance'. I am pretty sure the convergence test i described above would work pretty well for most Danish villages.

Regarding your wiki edits - i would strongly suggest you move the references to the perceived needs of certain applications to a separate section - these are not helpful to the mapper and also do not accurately describe the situation with these use cases (incorrect use of the term 'noise', subjective assessments like 'can be very helpful', 'can be very inaccurate'). Your edits make it much more difficult for the reader to actually understand the situation.--Imagico (talk) 10:46, 13 December 2017 (UTC)

Based on my experience, I'd argue that it's exactly the other way around. There's absolutely no way you can reliably infer an 'aggregate of urban landuses' from 'node based mapping' alone. Yes, in the case of i.e. Rødding, you could make an educated guess, but that's about it. I've been looking at a lot of urban areas and toyed around with a lot of place nodes over the years and I can tell you that there's lots of cases where you can't even do an "educated guess". And when you mention "functional center" I have to ask functional for what?. What are the use cases, what do you really need it for? I'd also argue that if you try to represent an urban area by a single node somewhere in the middle of it, you do exactly loose a lot of important information, that you would otherwise have if you had defined a reasonably accurate (multi)polygon around it. As already mentioned, there's no way you can reliably infer the extent of that area from a single node alone. I'd argue that to the extent that you really need it, yes, for lots of urban areas you actually can infer a reasonable "functional center". I wouldn't be all that happy if you did that though, because in my mind there are several equally important "functional centers" all over the village: The school, the former townhall, the sportscentre and "Rødding Højskole" to name the most important. If you try to represent the village with a single node alone, I feel that you loose the connection to all of those. --Hjart (talk) 14:01, 13 December 2017 (UTC)

I think you misunderstood me here - i did not say you can infer an aggregate of urban landuses from the node alone, i said you can infer it from the data which of course includes the urban landuse mapping. What you do when you manually construct an urban landuse aggregate can be much more reliably, much more objectively and with much less maintainance effort done using automated methods. Likewise determining the school/sportscentre/whatever else of Rødding with the existing data and a place node instead of a place area is perfectly possible. If your favorite geocoder does not support this that is not a good reason to introduce non-verifiable data to OSM.

Looking again just at the 'aggregate of urban landuses' interpretation - what you should ask yourself is: What verifiable information is recorded in the data of a place area outline that is not already available in the database without it?

For clarification - 'functional centre' refers to the function of the settlement as a settlement. Just think of the scenario: A friend calls you and says he wants to meet you in Rødding and does not provide any more specific information. Where would you first look for him? This cannot be determined from an outline geometry.

And once more i would suggest to separate the question of verifiability of the node based mapping of populated places from the verifiability of polygon based mapping.--Imagico (talk) 14:49, 13 December 2017 (UTC)

To me "the function of the settlement as a settlement" in this context reads as complete nonsense. You can't realistically point to any physical location and say "this is the function of the settlement as a settlement". I would definitely look for my friend inside that 'outline geometry'.

(Splitting the discussion here into verifiability of the node location when mapping populated places with nodes (here) and of the polygon outline when mapping as an area (below))

Now you are deliberately misunderstanding me. Settlements have a function w.r.t. human activities and interactions. That is the function of the settlement as a settlement. Regarding this function most settlements have a center which is distinctly different from any kind of geometric center of any outline of the settlement you might define. And this center can usually be determined in a verifiable way - for example using the method described above.--Imagico (talk) 21:23, 13 December 2017 (UTC)

I find it pretty hard to believe that my 'urban landuse aggregate' can be favorably replaced by 'automated methods' Can you show this to be true? As an example let's take http://www.openstreetmap.org/search?query=gedeager . The result shown currently lists 2 nearby, but unrelated places, both tagged on nodes. I always find this f*ing confusing, and I know I'm far from the only one because we just had a short discussion about it on the danish mailinglist a few days ago. How can any geocoder possibly determine that they are indeed unrelated, as long as they are mapped as nodes rather than areas (and because of that can't know their actual extent)?

--Hjart (talk) 20:23, 13 December 2017 (UTC)

I don't understand your example - that road is not within or near any urban landuse mapped in OSM so it is obviously also not within any aggregated urban landuse - no matter if manually or automatically generated. So what is your point here?

Ok, we can take an example mentioned on our mailinglist: http://www.openstreetmap.org/search?query=Englandsvej%2CSvendborg This lists a small village on the opposite site of town and doesn't even list the town. The guy had been experimenting in various areas around the country and didn't even succeed in finding examples that made sense for him. Same for yet another guy. Our conclusion was that mapping places as areas was the way to go. --Hjart (talk) 22:37, 13 December 2017 (UTC)

That seems to be a Nominatim issue and accordingly a case of mapping for the geocoder to shape the data to lead to desirable search results. I don't know why Nominatim returns this kind of result in your case but you could report it on https://github.com/openstreetmap/nominatim/. --Imagico (talk) 10:46, 14 December 2017 (UTC)

In case of Rødding i see no big problem with generating a similar aggregate (minus the inconsistencies pointed out above) automatically from a place node and the other OSM data in the area.

Please note that as i pointed out in the previous discussion above the whole subject of aggregated urban landuse mapping is ultimately of limited relevance here because even if you create a verifiable definition of this and want to map this despite it possibly being unnecessary you would still need to create a new tag or deprecate the other conflicting uses of the populated place tags on areas. Other interpretations of the meaning of a place area outline are currently at least as common as the aggregated urban landuse interpretation.--Imagico (talk) 21:23, 13 December 2017 (UTC)

If you see no big problem generating a similar or better aggregate automatically, why don't you show me how it's done? It's very possible that you think it's possible, but that alone is not enough to convince me. --Hjart (talk) 22:07, 13 December 2017 (UTC)

If i say it is no big problem that does not mean i can do it in ten minutes. I have enough experience with this type of data processing to reliably make this assessment. But i cannot make you believe me of course. As said this is not really the issue here.

In case of Rødding the following approach could likely work:

Determine the nearest other populated place and its distance
Take all urban landuse within about half of this distance around the place
Buffer them by like 300m and merge them
From that remove all separate disconnected sub-polygons
Take all urban landuses within this buffered and merged shape as aggregate urban landuse of the place

This is very simple and likely will not work well in most somewhat more complicated cases but there is a lot of data in OSM that can help making a better decision. --Imagico (talk) 10:46, 14 December 2017 (UTC)

I did not expect you to do it in ten minutes. Take your time. However based on all the nonsense and pointless bikeshedding I see in the discussions above, I will not trust your word alone. I want to see it demonstrated that you can realistically and reliably do a better job using automated methods --Hjart (talk) 14:47, 16 December 2017 (UTC)

The wiki indeed already states how to place nodes of larger settlements, and for the very small it is usually obvious, so I suppose this discussion is perhaps related to the more medium-sized places like suburbs and neighbourhoods. It is difficult to attract 100 voters for each of such entities (except in areas with tons of mappers, say Germany or Russia). In such cases, the sense that the place is symbolized by its original point of settlement may already have been lost due to integration with the larger settlement. There is also the case of such places artificially created by the local government without any obvious initial point of settlement or salient historic/cultural feature. So, I think that, in places with few mappers or without strong traditions, it would be ok to simply place the node near the major traffic interchange within that place (which is perhaps the most visited location within that place; though this might require proper highway classification) OR near the center of the built-up area (which can be obtained by finding the largest inscribed circle, usually pretty obvious; the largest quadrilateral might make more sense sometimes). This may also work quite well when you have only an idea of the approximate limits. Two years ago I've used (and documented in Portuguese but could translate) a slightly more elaborate version of the second method where I live. The results look good to me and nobody has complained so far - but please do if you think it shouldn't be so. --Fernando Trebien (talk) 12:27, 15 December 2017 (UTC)

Which of these render?

I noticed that the name of a place appears if it's tagged as a suburb or neighbourhood, but not if it's tagged as a quarter. Is there a list of which place types render and which do not? The table on this page has a column labelled "map rendering", but the entire column is blank. --Arctic.gnome (talk) 23:24, 13 December 2017 (UTC)

Please see https://github.com/gravitystorm/openstreetmap-carto/issues/798 --Hjart (talk) 23:52, 13 December 2017 (UTC)

Definition of settlement

Can we link the word settlement in the first paragraph to settlement geography for clarity across communities of different countries? --Fernando Trebien (talk) 11:22, 15 December 2017 (UTC)

I think it is also worth adding a link to settlement hierarchy. --Fernando Trebien (talk) 19:41, 15 December 2017 (UTC)

The link is probably ok (for the see also section) but we should have the relevant definitions here in our wiki and not on links to third party pages which we do not control, so if there is essential content in this article which we do not have here, let’s add it. —Dieterdreist (talk) 07:57, 6 August 2020 (UTC)

Use on Unpopulated Places

The values of 'island' islet', 'sea', 'ocean' and 'locality' may not be populated yet they are places and at least some of them have names. The present definition of the key places' excludes them yet the wiki page description goes on to include them. So, do unpopulated places belong in the key 'place'? If so the definition on the wiki page needs to be changed. Warin61 (talk) 09:17, 16 April 2019 (UTC)

place=ocean has some serious problems, but place=island has no problems and is widely used Mateusz Konieczny (talk) 10:05, 16 April 2019 (UTC)

In general, one may rarely say something useful and true about all values of a key. landuse=* is not only for landuses, some amenity=* are not made by humans etc. Mateusz Konieczny (talk) 10:07, 16 April 2019 (UTC)

Populated settlements classification criteria

We've been discussing this in Talk:Tag:place=hamlet#Hamlet_vs_Village, so I added a new section to the page explaining the criteria to classify a populated settlement. Feel free to discuss what features each populated settlement should have, and also the minimum population for each of them. I added this section because there was no clear criteria to follow worldwide. --Iagocasabiell (talk) 01:47, 5 September 2019 (UTC)

While I appreciate your desire to make a clearer distinction between the settled place tags, these features have been in use for many years and have established meanings in some places, which cannot be easily summarized in one algorithm. For example, in Denmark it appears there are strict population criteria used to determin if a place is a village, town or city, but in England the classification has more to do with history and official designations. In Taiwan there are currently no place=city under 250,000 people, but in other countries (including England) there are a number of cities with population of 10,000. While your suggestions are worthwhile and I use something similar myself when tagging places here in Indonesia, this page is probably not the right place to add this. Please discuss on each individual page, like place=village and place=town, and please try to document how the tags are currently used. If you would like to recommend a global way of tagging places which is different than the current "de facto" usage, the best option is to make a proposal and discuss it. --Jeisenbe (talk) 02:44, 5 September 2019 (UTC)

Yes, I wasn't sure were to put this, I know how to create a proposal for a tag, but how would I name the page for a proposal like this? Thanks for the feedback. --Iagocasabiell (talk) 10:17, 5 September 2019 (UTC)

You can create a proposal with any sort of name, like Proposed_features/Populated_settlements_classification or whatever sounds most descriptive, then remember to send out a message to the Tagging mailing list or other forums to get more discussion. --Jeisenbe (talk) 14:15, 5 September 2019 (UTC)

Done: Proposed_features/Populated_settlements_classification. I don't know how to send it to the Tagging mailing list, can someone help me? --Iagocasabiell (talk) 01:46, 7 September 2019 (UTC)

I could do it for you, but it would be better to subscribe so that you can respond to comments and suggestions yourself. You can sign up for the list here: https://lists.openstreetmap.org/listinfo/tagging/ - then send an email to tagging@openstreetmap.org with your comments or questions. Also see the page Proposal_process if you are interested in doing the whole formal process; there's details about what to do next. Thanks for working on this! --Jeisenbe (talk) 07:04, 7 September 2019 (UTC)

Mapping populated places as areas for addressing schemes

The English page contains a section that unambiguously discourages mapping populated places as areas and lists several arguments (which I personally find quite persuasive). However, mappers in certain regions adopt addressing schemes that require using the place tag on areas of populated places. The most prominent example is Russia: Addresses#Russia. A very similar approach is used in Ukraine. Here is one summary I was able to find (in Ukrainian): User:Larry0ua/Адресація_в_Україні. Moreover, many Russian pages on addresses and countless forum discussions refer to the practice of using the place key on areas as common knowledge. It is even mentioned here on the discussion page as a supposedly established practice. The rationale behind it is that having a place marked as an area allows the software to derive the address information based on objects being within the area’s boundaries, which removes the need for several addr:* tags. Several examples are mentioned on the Russian Addresses page of a successful utilization of this approach. With this in mind, I believe this should be mentioned on the place key page as well as pages of populated places (e.g. place=city, place=town, place=village, etc.) in the Usage section. Here is my initial version:

It is worth noting that mappers in certain regions adopt addressing schemes that require using the place tag on areas of populated places. More details can be found on the Addresses page.

It has since been removed because the linked pages did not mention the described practice. However, the linked section reads: “Places are polygons with name and addr:country; optionally addr:region, addr:district and addr:subdistrict” (“polygon” being the term used for area in Russian). Here is a more detailed description on Russian page on addresses: Для населенного пункта тег place=* ставится на полигоне, обозначающем границу населенного пункта. (for a populated place the place=* tag is used on an area of its border). And again here: “Населённые пункты нужно обозначить как полигоны с тегами place=city/town/village/hamlet/isolated_dwelling” (populated places should be mapped as areas with place=city/town/village/hamlet/isolated_dwelling tags). I suggest we add this information back to inform the community about why so many places are mapped in this manner.

"The rationale behind it is that having a place marked as an area allows the software to derive the address information based on objects being within the area’s boundaries" - usually boundary=administrative relations are used for that Mateusz Konieczny (talk) 17:51, 1 June 2020 (UTC)

Exactly. Are there any examples of a place that is mapped as an area but cannot also be mapped as an boundary=administrative area as well? In the USA it's very common to have a place=city tag on a town or village which is a "municipality" due to some low-quality imports, but all of these are more appropriately mapped as boundary=administrative + admin_level=8 in the United States. --Jeisenbe (talk) 19:35, 1 June 2020 (UTC)

It is true. In fact, this approach is acknowledged in one of the pages linked above: В некоторых странах для этой цели используется boundary=administrative или даже просто ближайшая точка населенного пункта. (in some countries boundary=administrative is used for this purpose). However, it does not change the fact that Russian and Ukrainian addressing schemes use place=* for that purpose. There are certainly examples where administrative boundaries cannot be used for purpose of addressing schemes due to the peculiarities of administrative and territorial division in Russia and Ukraine. However, this is beside the point. My intention is neither to encourage the practice nor justify it – only to inform the community about its existence. This is why I have added the clarification after the arguments against using place=* on areas and phrased it to make it clear that it is a country-specific approach that is not universally accepted. Many mappers consider it the correct approach (in no small part because it is documented on English and Russian entries on addresses) and will map populated places as areas whether we add this information or not. However, without it people will need to spend much more time researching the topic trying to figure out why so many places are mapped in this manner. --Ungoose (talk) 09:28, 2 June 2020 (UTC)

I think from what you describe as the address mapping system in Russia the place polygons used fall under the third variant documented on the page: An approximate hull polygon drawn around all parts of the populated place but not meant to represent a meaningful outline. Any more specific instructions how such place polygons are drawn in Russia (in particular what kind of places that are not administrative units are generally considered part of Russian addresses) should be documented - but not on place=* but on either the individual tag pages of the place types in question (as far as documentation goes how these are mapped) or with the documentation of the address mapping scheme. --Imagico (talk) 10:59, 2 June 2020 (UTC)

I agree with all of the above. It does more or less fall under the third variant, and specific instructions should be documented on respective pages - in fact, they already are (as you can see following the links above). Note that I am not after a detailed instruction here - only a two-sentence clarification at the bottom of the Mapping populated places as areas section, which is dedicated to this exact issue anyway. I also agree that relevant place type pages should have it as well (city, town, and village at the very least) in the Mapping *** as areas subsection which, again, addesses this specific issue by summarizing the Mapping populated places as areas section (which is why I feel it would be an appropriate starting point).--Ungoose (talk) 11:22, 2 June 2020 (UTC)

If there are no other objections, I am going to add the clarification back. It was initially removed because it was supposedly "not mentioned at the linked page or the citation in the Russian-language forum" (which is demonstrably false) and it is an important information mappers should be aware of.--Ungoose (talk) 09:51, 11 October 2020 (UTC)

I disagree. The text made it sound like this method of mapping place=* features is needed for proper addressing, but that is not correct, since there are boundary=* features which can be used instead. Since this English-language page is a global overview, it should not mention unusual mapping methods which are only common in 1 country. --Jeisenbe (talk) 15:46, 11 October 2020 (UTC)

I was very careful not to make it sound like that. Can you think of a better phrasing that would make it clear it is not needed for proper addressing and is an unusual mapping method? Like maybe adding the remark that boundary=* features can be used instead? I think the English page should contain at least a discoverable link to a place where more information can be found on the subject. There are hundreds of villages, cities, and towns mapped as both nodes and areas, and without this information on the main page they look like results of bad edits or someone's misuse of a tag.--Ungoose (talk) 17:01, 11 October 2020 (UTC)

Urban boundary vs place area

boundary=urban may be conceptually more elegant than place=* on areas, at least from the standpoints of data consumers and verifiability. So, for example, one may add place=municipality+boundary=administrative to an administrative boundary, boundary=urban to the urban contour (estimated from knowledge, from imagery, or, if available, official), and place=city to the label node. --Fernando Trebien (talk) 03:19, 16 July 2020 (UTC)

Move "borough" to administratively defined place values

If I did not understand it wrong, it seems that "borough" is about an administratively defined entity and should be moved, right? --Dieterdreist (talk) 23:09, 5 August 2020 (UTC)

Discourage use of place values which are duplicating administrative entities

Why do we still need values for "Administratively declared places"? Can't these be sufficiently described by boundary=administrative and admin_level=*? I propose to deprecate these tags, in particular: country, state, province, district, county, municipality and "region" in case it is about an administrative entity. --Dieterdreist (talk) 23:13, 5 August 2020 (UTC)

There is no problem in deprecating place=country, place=province and place=state because all are mapped as administrative boundaries. However, some countries still do not have complete mapping of districts, municipalities and county equivalents, so it should be mentioned that these tags are still used in places where administrative boundaries cannot be determined or are uncertain. For example, in Papua province, Indonesia, the admin_level=6, =7 and =8 features in the interior have undefined boundaries. There are no accurate government maps or databases, and local people in the districts cannot tell you the exact boundaries, but they always know where the district office is located, so the center can be mapped as a node with place=county or place=district --Jeisenbe (talk) 00:43, 6 August 2020 (UTC)

Underlying that, fundamentally a place=* and the associated boundary=administrative are different concepts. The former is more abstract and diverse, the latter is clearly defined. They should co-exist. Locating the point of place=* near the admin_centre or as the label is a result of representing this. -- Kovposch (talk) 07:27, 6 August 2020 (UTC)