Talk:Key:place

Contents 1 Commas 2 Transport restrictions? 3 Distinctions 4 Howto 5 Difference between name and place_name 6 Importance 7 Suggestion on changes on place tag 8 City contour 9 Tagging areas 10 How To Tag 10.1 How much needs to match? 11 The "city" distinction: recent wording disagreement 12 Farm vs. Isolated Dwelling 13 Place=* world wide default unification 14 Routing and Places 15 Name rendering on polygons 16 Place or/and administrative boundary 17 Places and administrative boundaries

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)

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)

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)