It seems to be common practice to tag the capitals of the countries on our planet not only with capital=yes, but also with admin_level=2 in order to identify them as capitals of a country (see Overpass). This use of admin_level on capitals is not really documented anywhere in the wiki, only mentioned indirectly (the page on Key:admin_level writes: “It is also used with other types of objects that are associated with government entities. For example, see Key:capital.” - but the page on capital does not explicitly mention this practice).
However, the use of admin_level=2 seems unfavorable to me, e.g. because:
The information is redundant to the fact that the capital is also part of the state relation as an admin_centre,
A city can be the capital of different admin levels (e.g. a state and a province).
I am not familiar with admin level and capital tagging at all, but this practice does not seem particularly consistent to me. Perhaps you share my wish for a better structure and possibly better documentation here.
The specific reason why I came up with this is that someone recently removed the admin_level=2 tag from the city of Berlin (capital of the state of Germany; see this OSM note). As one of the few (maybe only?) capitals in the world, Berlin now no longer appears on the Humanitarian Map Style because of this. I’m rather unwilling to add the tagging only for the renderer again, as it doesn’t make much sense to me - but the Humanitarian Map Style is unfortunately (afaik) no longer being developed, so it can’t really be fixed there either. Other larger map styles don’t seem to be affected as far as I can see.
This is only referring to the numeric values being shared with the capital=* key. It isn’t saying you should tag the place=city node with admin_level=#.
On place nodes, admin_level=# seems to be essentially an alternative to capital=#. The two keys are common at different levels:
Some of the difference is regional. A lot of the admin_level=# usage seems to be the result of copying the tag from a boundary relation to its label member, sometimes accidentally. This inherently contradicts the old idea of tagging capital=yes and admin_level=#. Any data consumer using that interpretation would think lots of cities are capitals of themselves.
The style originally labeled national capitals based on the undocumented, stagnant is_capital=country tag, then later switched to looking for capital=yesadmin_level=2. By contrast, OSM Carto, OpenMapTiles, and Shortbread all look for capital=# (with capital=yes being an alias for capital=2). Development on the Humanitarian style stopped years ago, and the repository is now archived, so I’m not sure we should place much weight on its quirks at this point.
Practically speaking, yes. However, technically, capital=# says the city is a capital (at a certain level of government), and the admin_centre role says what it’s a capital of. We have some similar tagging schemes that bind features to their referents, such as destination_sign relations, but such relations are fairly rare overall.
More renderers support capital=# than admin_centre. By the time database conversion tools added support for admin_centre, it had already gotten thoroughly confused with label, making data consumers pretty reluctant to do much with the role.
For what it’s worth, the U.S. community decided a year ago to tag capital=* comprehensively, decreasing our reliance on admin_centre. We kept these roles for completeness, because some administrative units and their capitals don’t neatly fit into the admin_level=* hierarchy, and because some capitals lie outside the areas they administer.
OpenHistoricalMap also soured on admin_centre because it would force us to duplicate a boundary relation every time the seat of government moves to a different city or the city changes its name or status. Instead, if a data consumer really needs to figure out which city is the capital of a given area in the general case, then it can infer the relationship spatially or using Wikidata. The same could be true of OSM, too, but admin_centre is pretty widespread as things stand. I don’t see the redundancy as being any worse than boundaries versus their label members.
Could it be possible to solve this and another issue being duplication of places (place node and boundary relation, which in my opinion are the same feature) with introducing a capital role that should be applied to only empty nodes?
This relation would then get the place tag also. Then renderers could render the labels in the place of this node.
Also adding support for place=* on areas would be nice.
The main issue this fixes is having to update tags like the population or adding name:xx on two objects.
Could this make it still possible for software to treat such nodes in the same way?
If so then it would be even better to add nodes with a general centre role to multipoligons which could render its label in that place but I’m getting ahead of myself.
This is an oversimplification that would exacerbate the tensions around place classification.
As things stand, a place=* point represents one of two things:
The geometric centroid of an administrative area
The conventionally accepted centerpoint of a human settlement that has no formal boundaries (e.g., an urbanized area, a neighborhood)
Data consumers are largely capable of computing the centroid automatically, so we should deprecate this usage as redundant. If we were to eliminate these points en masse today, some data consumers would break, but surprisingly not the usual suspects. (OSM Carto prepared for that many years ago.) I think it would be safe to delete centroid points for very local administrative areas, such as barangays in the Philippines, but we should wait a while longer for more prominent features like states and countries until stragglers like OpenMapTiles switch to using the boundary relation.
On the other hand, in many countries, the place point of a named settlement only has a tenuous relationship with an administrative area by the same name. We need to keep these concepts separate to prevent confusion. The boundary should not have a place=* tag, and the place=* point needs to reflect the settlement more holistically. Renderers can avoid duplicate labels by prioritizing the label member when present. (OpenHistoricalMap’s main renderer has implemented this approach, and database cleanup is underway.)
Several related issues are explained in more detail in these conversations:
I’m not really talking about the first usage since I’ve already taken it for granted and my main point is that we don’t want the labels to be in the centroids for things like cities or towns. But yes, the centroid is fine for anything higher than that such as counties or states.
I fully actknowledge the 2nd usage but my post refers to situations when the exact boundaries are known and already mapped. I believe it’s violating One feature, one OSM element - OpenStreetMap Wiki because there exist 2 objects with the same name which often have the same tags like population.
I simply wanted to introduce a role (maybe called centre), mainly for cities and places with a known exact area, which would be placed in the middle of e.g. a square – basically where place nodes exist right now.
This would replace the label role which already sounds like tagging for the renderer. centre as a name would be better because it’s representing the most populated place, the social centre which has implications not only for rendering. Also the new name shows that it’s a different thing.
This role would be used on an untagged node to avoid duplicating tags.
My question is: is it possible for software to support this? Can this idea work and be rendered, etc.?
I have a more nuanced perspective. Most of the time, what we think of as a “city” is actually two real-world features: a human settlement and an administrative area that happen to share the same name. So of course there would be two elements in OSM. For convenience, laypeople often think of them as one and the same, and in some countries, they might be coextensive. But these are regional assumptions that really break down in some countries (starts around 15:30), not something we can base a global tagging scheme on.
For context, I’m coming from a country where settlements spread organically, usually with minimal planning, and administrative areas often try to approximate these development patterns until they give up, sometimes with spectacular results. When someone wants to go to Atlanta, they don’t particularly care about the outskirts; better to take them to the city center – specifically, the Five Points intersection, the origin point of the city’s street grid.
Meanwhile, any renderer that sizes city labels by population needs to consider the full population of the Atlanta urban area, not only the administrative City of Atlanta but also giant but obscure suburbs like Sandy Springs. In fact, more than half of Atlanta’s urban population lives outside any local administrative boundary, in unincorporated areas such as what the Census calls “Northeast Cobb CCD” for statistical purposes. (We don’t map any of these purely statistical areas, which would resemble cadastral mapping at high zoom levels.) Ideally, the Atlanta boundary relation would have population=498715 while the Atlanta place point would have population=5100112 – a different order of magnitude.
Incidentally, the administrative area’s name doesn’t necessarily match the settlement’s, even if they are very closely related. In New York, two adjacent settlements can be peers and share the same name, but their administrative areas have different designations and thus different name=* tags. I understand this is also the case in other regions with English influence. But plenty of other countries make a similar distinction between the settlement and the boundary. In fact, in China, the lowest-level administrative area is so often so much larger than the main population center that the local community had to be talked down from redefining population=*.
Your POV seems to be very USA-centred but it doesn’t function like that everywhere.
Of course every big city today like Warsaw was once a small village that had the nearby villages merged with it and that’s what became the new Warsaw. The land that the original village was made of is usually now called ‘the old town’. The meaning of that city’s name has changed.
The administrative borders are acknowledged by people, traffic signs that show you when you’re leaving the city, train station names no longer showing ‘Warsaw’ as prefix, and the fact that a village next to the administrative borders is appealing to some because housing is going to be cheaper there.
Also there still needs to be this representation for smaller villages or towns that have very clear borders, maybe even observable in-person but with the real center a bit distanced from the centroid.
Can you say how the mapping of Warsaw would change inder your proposal? I see Warsaw has an admin_centre role but no label role. I thought you were talking about replacing only the label role but I’m not sure.
It wouldn’t be possible to replace admin_centre with an untagged node in many places for some.of the reasons @Minh_Nguyen gave, which apply in many more places than the US.
To give a European example: In Spain, cities and towns are often loosely conflated with their municipalities, which have well defined borders. But a distinction is made in some contexts, including OSM. Looking at Malaga, for example, the situation superficially looks similar to Warsaw but there is a difference. Several tag values are different between the place node and the municipal boundary, including wikidata, population, and tags relating to INE, the national statistics institute. INE defines the population of the city versus outlying areas using census boundaries which have no role in everyday life. There is no administrative unit that even roughly matches this - the municipality is too large and includes large areas of unpopulated mountains, while districts, the next admin level in use, are too small.
That’s probably because cities already don’t render a label in the middle. But that’s besides the point.
My proposal deprecates label and also removes place=* on nodes when an administrative boundary relation exists. So then, the node that used to have the place=* tag has all of it’s tags removed and transferred to the relation, the centre role is applied to the node and renderers display everything the same way — this untagged node renders in the same way it did before because it has this centre role in the relation.
I’m pretty sure that in these cases the Atlanta urban area is a different thing than the entire city of Atlanta.
That’s an interesting example. In Poland the biggest cities have powiat (county) rights so I guess they could be mapped as place=county also but we don’t do that.
This particular case with Malaga illustrates perfectly when place=* nodes are still useful. It’s the same for small villages without defined administrative boundaries.
Though I think the node should be tagged as place=city representing the city with no defined borders because the municipality does have them.
I do not think, actually, while the examples were from the US, I think we can generally assume that there is no 1:1 relationship between administrative entities and socio-geographic entities (place), even if there may be many cases where there is.
Of course, it’s impossible to generalize, and that’s the point. I don’t think we should eliminate one kind of feature due to an assumption that it’s always redundant to the other, when we know the assumption will generally break in some parts of the world. Better to make sure the two features are linked but distinct, so that data consumers can easily deduplicate them as needed.
It’s a different thing, but data consumers need to be able to conflate them depending on the use case. A local political map will distinguish the City of Atlanta from its suburbs, and the unincorporated places will go unacknowledged. By contrast, on a topological or transportation map, the city limits may be present as a subtle dashed line, but it’ll matter much less than the city (labeled as a dot or star) surrounded by a sprawling built-up area (highlighted in yellow).
Regardless of the map’s theme, at low zoom levels, the city’s prominence should relate to the overall urban or metropolitan area rather than the city proper. Otherwise, cities from London to San Francisco get swamped by places you’ve never heard of, while cities all over China will get overamplified because of large populations in satellite cities that lack separate administration. Tightly coupling human geography to administrative geography is how mappers and developers grow desperate enough to propose falsifying population counts and arbitrarily assigning one city’s population to another city.
Granted, the status quo of label members for populated places leads to some duplication and maintenance overhead. I see that as an argument to stay focused and avoid stuffing too many tangential attributes on both features like coats of arms and names in constructed languages. Wikidata can store a lot of this information – not to mention the detail about which administrative areas a city administers.
But as to the original question, I think it’s pretty clear that admin_level=* should not serve two contradictory purposes at once on potentially the same feature (especially if the boundary hasn’t been mapped out yet).
You’ve misunderstood me. I want to deprecate label because it sounds like tagging for the renderer anyway. But that doesn’t even have to be done. I want to introduce this centre role to prevent duplicates and in cases where you say it can’t be applied, I’d like to look at them individually because I believe, that it can still be used.
So I checked it and I see that in OSM there is the city of Atlanta mapped and there’s Sandy Springs. You mentioned that we don’t map the merged are because it’s purely statistical. My question is: why? If you say that the combined Atlanta should be represented by the node with population, why can’t the area be imported too (e.g. as boundary=statistical)? Then both objects will have sperate population. They could even share the same node as the centre.
In principle, we could import these boundaries, update the geometries annually, and reimport them every decade when the Census Bureau discards the old ones and recalculates new ones from scratch.[1] This would be very convenient for analytical purposes, helping people avoid the pitfalls of aggregating demographic data by administrative area or postal code. However, the formally described edges of an urban area are extremely complex, since they correspond to census blocks and the algorithm doesn’t compact the boundary very aggressively. It’s practically raster data.
I only proposed using the urban areas or something similar to determine more realistic population figures, from which we can derive less arbitrary place=* classifications. Even though we wouldn’t import the geometries, they would allow us to objectively identify places that are suburbs[2] within an urban agglomeration. Some cartographers have opted for a more holistic approach, but although the results are more reliable and generalizable globally, I find the process to be too opaque and elaborate to explain to a mapper, let alone a map user.
Officially, a 2020 urban area has nothing to do with a 2010 urban area by the same name. ↩︎
In the North American meaning of the word, not the same as place=suburb. ↩︎
Alright, I suppose in this case it’s better to leave it as a node, though I’m not sure if it should still be tagged as place=city. In case that it is, it should be specified with a note=* that it’s not just the city of Atlanta but a wider region. I’d then recommend adding a seperate node to represent the city of Atlanta itself and add that to the boundary relation.
But you’re just talking about these specific cases and ignoring those, where the one feature – one OSM element rule is actually violated.
My main question is if my concept can work from a software POV because I think I remember somebody saying that renderers cannot detect the object’s role. If I’m just misremembering things or this is no longer an issue, I may formulate a full proposal.
Atlanta is not a one-off exception, just one that illustrates the issue particularly well. I’d even go as far as to say that the worldwide norm is that place=city at least implicitly represents something orthogonal to an administrative city jurisdiction, sometimes bigger, sometimes smaller. It only matters for certain purposes, which is why we normally don’t fret about it too much.
For sure, if we end up tagging a population=* on the place=city node that doesn’t correspond to something mappable, we’d definitely need to add population:note=* or similar to clarify which record in the source we’re using. Another hint would be that, ideally, Wikidata would have a separate item for the populated place versus the administrative area, which wikidata=* would then point to. (It’s currently common in some parts of the world but not others.)
I don’t think there’s a straightforward answer to this question. As an engineer, I’m trained to tell you anything is possible, with enough pain. OSM data is used by a wide variety of software stacks with diverse capabilities and performance characteristics. imposm might well be capable of importing untagged centroids based on the boundaries they’re a member of. But an Overpass query for city centers would be rather impractical if you don’t have any primary feature tag to key off of. There’s already a similar situation with the untagged member ways of a boundary relation. Editors like iD support this tagging scheme, but it creaks a lot when you hold it, lots of bugs because of the awkward data model.
I do like where you were going with naming it centre. In retrospect, label was an awful, awful name for the role.
It’s not an issue. I did say that such a region should be rather mapped as an area because it doesn’t have any administrative grounding. You even said that those areas that change every couple years could be imported each time. I also said that the administrative city itself should have it’s own object as it’s a separate feature.
It might not be a one-off exception for the U.S. but not necessarily for the whole world.
That could be called an agglomeration or a metropolitan area. But the city itself is a city defined by the borders. There are exceptions like Malaga which don’t have its city borders defined which is why it should stay mapped as a node but e.g. every city in Poland has a very well-defined border. Anything outside it is considered to be part of the city’s perihery.
Of course, there should be a distinction. In Poland there’s no official statistical areas like this so its impossible to calculate the exact population if everybody considers different villages to be part of the urban area.
Does this mean the same happens with large multipoligons?
Then admin_centre could also be split into capital and capitol since the current usage is basically using it for either and also very commonly instead of label. I think it’s a good idea to make it all new roles to signify it’s got a concrete meaning now.
This is precisely the issue: at certain scales or in certain themes, a map is going to ignore local boundaries while marking the general location of cities as point features within agglomerations, typically prioritizing them by attributes such as population and capital city status. The map necessarily conflates the city proper with its periphery (what North Americans call suburbia). City limit signs do not matter, because this depiction has nothing to do with the city as an official designation.
This concept of place is probably more difficult to understand if you live in a country that is completely partitioned into administrative areas that are completely partitioned into more local administrative areas and so on, and if an urban administrative area is fully urbanized and a rural administrative area is fully rural. It reduces the question of which city you’re “in” into which administrative area you’re in. This is a common situation in many European countries, some of their former colonies, and even parts of the U.S., but far from universal. (The UK notoriously lacks any such hierarchy, and it used to be even worse.)
The bbox would need to be small. You could not practically query for all centre members of boundary relations representing cities globally or even in a mid-size country. (You’re also assuming cities are always admin_level=8, whereas border_type=city would be more accurate.) You’d want to be able to say node(r:centre) without the other line, but that doesn’t work at all, and recursing up and back down only worsens performance.
The fact of the matter is that there are plenty of use cases for understanding the locations of cities independently of their boundaries. Bringing boundary relations into the picture massively complicates any attempt to work with these locations when the boundaries are irrelevant.
To some extent. There are five Great Lakes in North America, but occasionally we lose a lake and can’t find it for a while. Part of the issue is that, until iD happens to download enough of a relation, it can’t run the full consistency checks or even know to highlight the way as part of the multipolygon or boundary. The same would be true of a tagless centre node.
It’s even worse in JOSM, which allows partial downloads via Overpass queries. Let’s say a city boundary’s centre member is a famous historic=monument node in the central square. This form of dual-tagging is quite possible because a centre member would have no tags otherwise. Later on, the monument gets moved to a different neighborhood, so a JOSM user downloads the node by ID and moves it. They’ve moved the “city” without realizing it.
Malaga is not an exception - I was describing the general situation in Spain and just gave Malaga as an example in case someone wanted to look at it on the map.
I think you are heavily influenced by the administrative structure of Poland, seem to underestimate the variety of other systems, and dismiss examples of these systems as “exceptions” as you have done for both Atlanta and Malaga.
I could give Ireland as another example of a country where your idea that “the city itself is a city defined by the borders” doesn’t hold. It might be just about possible to interpret a handful of the largest cities in that way, but not the majority of towns.
Incidentally, admin level 8 in Ireland is mainly for local government units outside cities, often consisting of mainly rural areas with perhaps a medium size town as admin centre. Within cities the admin levels typically skip from 7 to 9.
Out of curiosity, if there was a reform of local government in Poland and Warsaw was split into, say, Warsaw East and Warsaw West for administrative purposes, would you consider that there are now two cities that should have two centre nodes?
There seems to be some confusion about whether “admin_level” refers to the administrative level of the capital city or of the country of which the city is the capital. I recently reverted an edit to Ashgabat, capital of Turkmenistan, which, if you consult Tag:boundary=administrative, should be admin_level=8 since 8 is the level assigned to cities (and towns, too). Somebody changed 8 to 2 and annotated it claiming that the admin_level of the capital should reflect the admin_level of the entity of which it is a capital. Perhaps the wiki entries on admin_level need some editing to clarify all this.
I have no problem with the capital=2 designation of a national capital, which should work for rendering maps that want a special symbol for national capitals. If a city is capital of multiple jurisdictions (country plus state/province, for example) can we not use the semicolon to separate multiple levels, e.g., capital=2;3?
