capital
Status:	Draft (under way)
Proposed by:	*
Tagging:	capital=yes/no
Applies to:	node
Definition:	The administration capital of a nation or a state
Rendered as:	same as city or town, except rendered with a star
Draft start:
RFC start:	*
Vote start:
Vote end:

Contents 1 Proposal 2 Discussion 2.1 Combination with admin_level 2.2 Use the relation boundary 2.3 true or yes 2.4 Capital has sense only when used in context with region 2.5 Directly attaching the admin_level to the capital-tag

Proposal

To indicate the administrative importance of cities, the proposal is to make a `capital={country|province}` tag on city nodes for the respective capitals. A few capitals have previously been tagged as `is_in=capital_cities` or `is_in=capital cities`, but 1) the information is better represented as a separate tag and 2) very few capitals are marked that way, so there are probably less than 10 nodes worldwide to change.

The information in the capital tag is useful for rendering low zoom levels because the some capital cities have a population comparable to towns in other countries. There is no other information that indicates the importance of cities.

Discussion

I have already added the capital=country tag for most of Europe. (Einarr 22:55, 7 February 2008 (UTC))

Combination with admin_level

I guess we should also have admin_level=* which specifies the highest admin level that a place is the capital of. E.g. Berlin is the capital of Germany, and should thus have admin_level=2 (according to Key:boundary and Hierarchy of places). Would that be enough, or must admin_level be a list? --Colin Marquardt 16:03, 21 February 2008 (UTC)

I agree that admin level should be specified. Either capital=yes admin_level=2 or make it short capital=2 --Jttt 07:18, 3 June 2008 (UTC)

capital=yes wouldn't work, because it is ambiguous if it's the capital of admin_level 4 and 6 for example. capital=2 needs either to be expanded to a list of admin_levels=2;4;6 or to something like capital_2=yes, capital_4=yes (the latter would be a easier for renderers). --Eimai 08:44, 3 June 2008 (UTC)

I meant capital=yes and admin_level=4 will be used together so it's clear city is capital of admin level 4. I don't see why capital=2 needs to be expanded. I thought that when city is country capital then it's implied it's also capital of surrounding county/district. --Jttt 08:59, 3 June 2008 (UTC)

That's incorrect. A city can be a capital of a larger administrative unit without also being a capital of the smaller unit it's located in. To give two examples: Ottawa is the capital of Canada but not the capital of the province of Ontario, in which it's located, so that Ottawa is capital at admin_level 2 but not admin_level 4. Likewise, Lansing is the capital of the state of Michigan but not the seat of Ingham County, in which it's located, so that Lansing is capital at admin_level 4 but not admin_level 6. I grant that such cases are rare, but they do exist, and we should develop a data structure that supports them. --Marnen 15:03, 22 June 2008 (UTC)

capital=yes and admin_level=* and only the highest value where one city have several admin levels (if it is a national and provincial capital, tag it only as national). If relations are linking both the borders and the capital than there will be no doubt where the capital is anyway. --Skippern 12:47, 2 December 2008 (UTC)

For areas with heavy population (i.e. several towns and cities in the vicinity) around a nation or state capital, the state capital should have priority to be rendered even though a city close by have higher population. --Skippern 23:00, 2 June 2008 (UTC)

Why not use admin_level=* without capital=yes? --Aleksandr Dezhin 13:24, 16 September 2009 (UTC)

Use the relation boundary

What is the reason we cannot use a relation and refer to a node/relation to point out its capital? --Skinkie 15:36, 12 November 2008 (UTC)

Rendering? --Skippern 19:27, 27 November 2008 (UTC)

Improve your renderer :) --Skinkie 04:44, 21 December 2008 (UTC)

The administrative importance of places is a general issue, not reserved to countries/provinces. Administrative boundaries are already defined by the relation boundary. So, instead of starting with capital=country;region;municipality or admin_level=4;6;8, I would suggest to simply attach the place node to the relation collecting the administrative boundary. See my proposal here: Talk:Relation:boundary#Add_the_node_place_in_the_relation -- Pieren 12:00, 2 December 2008 (UTC)

That would make it harder to just collect capital places for one or another level. The respective program would have to read in and process all boundary polygones.

From my feeling the place should have a mark by itself, not only get it because it's listed in another feature.

But I also like the idea of adding the node to the relation. Would be having both that bad? --Frawe 09:53, 19 July 2009 (UTC)

Yes, as of the current state (Feb. 2011) it seems that both methods are used. capital=yes for capitals of admin_level=2 and capital=<highest admin_level> e.g. capital=4 for a regional capital (region assumed as area with admin_level=4) as well as a boundary relation, where the admin role is inserted. This (double) approach has the benefit to allow easy tagging and evaluation of the administrative importance without even looking at the relations on one hand (sufficient for many use cases, easier to map, more stable then a relation), and a precise modeling of the administrative realities (capitals are often capital place for several admin_levels) with the relation on the other hand. -- Dieterdreist 15:28, 7 February 2011 (UTC)

true or yes

Lots of other tags use something=yes instead of something=true. Ojw 21:34, 8 February 2009 (UTC)

A way to solve that is to say that when something=no/false or non-existant, than it is untrue, all other values are true, in that way, yes/true/random text have the same value. If it is desired, the random text can be filtered to give various other outputs. A discussion on capital can be if capital=nation or capital=yes + admin_level=2 should be the correct way of doing it. My preference is on using admin_level. --Skippern 13:27, 2 May 2009 (UTC)

Capital has sense only when used in context with region

As user Marnen has shown on the Ottawa case it is necessary not to only tell, that a city is a capital, but also capital of what. I suggest therefore to merge this proposal into proposed Relation:Region, where each capital is bound to region and also type of the capital is noted (if is is administrative, religional etc.). --Jakubt 18:20, 26 August 2009 (UTC)

Does relation work if there are only the administrative places but not (yet) the boundaries of the regions as e.g. currently in Thailand? Willi2006 12:00, 29 April 2010 (UTC)

Yes, that's the point. The relation is only working for places with valid boundaries and still it is much more complicated for map generators to evaluate. capital=yes has become a de-facto-standard and should IMHO be kept as a fallback even when relations are in use. This would not be the only situation where we have simple tags on the object to backup a relation. -- Dieterdreist 15:03, 21 January 2011 (UTC)

Directly attaching the admin_level to the capital-tag

I propose to keep the usage capital=yes for national capitals as it seems currently implemented in the data as well as in the mapnik rendering rules. For capitals of lower levels we started tagging them as capital=4 for capitals of an admin_level=4 and capital=6 for capitals of an admin_level=6, but it is possible to extend this also to lower levels like level 8. All these directly on the main place node (or area if areas become popular). -- Dieterdreist 15:00, 21 January 2011 (UTC)

I found that this method (capital=6) is according to taginfo the preferred tagging scheme to tag administrative centres lower than national capitals. -- Dieterdreist 14:33, 26 January 2011 (UTC)

On admin_level=8 there are a lot of cases where the are several villages in one community. To mark the main village, which is the adminstrative center of this community, it could be tagged with capital=8. Wolfgang Barth 14:57, 27 September 2011 (BST)

= Voting =