Hello! I have noticed while browsing osm.org and querying features, that boundary tags have a name based on admin_level. These names are quite anglocentric (including counties for example), and given the vast difference in admin_level usage between countries, often wildly out of place.
Is there any way to do this dynamically? Failing that, can anyone think of a more neutral way of labelling this stuff?
It isn’t even anglocentric. I’m pretty sure the set of translations from admin_level=* to English on the website doesn’t fully correspond to any country in any dialect of English.
It’s part of my larger proposal to fix the situation where the website has two British Englishes and zero American Englishes, causing confusion and warping OSM tagging. Unfortunately, there’s some strong opposition to changing the site’s vocabulary, apart from trivial spelling fixes. But maybe we can get some traction behind these more generic terms too.
Labeling boundaries based on admin_level=* is inherently difficult, because this key basically only indicates how deeply nested the boundary is in a hierarchy. In geocoding, this information is essential for arranging the containing boundaries’ names, but it isn’t really relevant enough to display to the user as a “type” of boundary. Ideally, the site would use a second key such as designation=* or border_type=* to determine the jurisdiction’s formal designation in real-world terms instead of OSM terms.
I quite like your proposed generic terms, even though I disagree with the spirit of the rest of the rewrite towards American English. I won’t expand my reasoning in detail here.
Perhaps it is worth splitting it off into a separate pull request, as it is likely to gain traction from many different communities, even outside the Anglosphere (translation of these terms are generally based on the English versions, and are similarly weirdly out of place).
this wouldn’t be very helpful IMHO, e.g. using the same generic term for level 4 and 5 in Germany. We should have country specific names that correspond to the actual names and levels in the country, and possibly use additional tags where the admin levels are not sufficient
For sure, reusing the same label across multiple levels isn’t as helpful as using a distinct label at each level, but I think it’s still more helpful than producing a misleading label at almost every level. It would be a workaround for the already poor idea of labeling boundaries based on admin_level=* alone, but I agree that it would be much better to label boundaries based on designation=*, border_type=*, or admin_type:PH=* (which I just learned of). If Nominatim could expose these keys to the website, then the website would no longer need to generalize.
And these labels can be wrong and so even more misleading than the current ones. In the case of France, I wouldn’t consider a departement as “local”, even if it’s admin_border is level6. The departement Moselle covers a larger area than two of its neighbours, the German federal state of Saarland, admin_level=4 and the country of Luxembourg, admin_level=2 combined
I was assuming that smaller countries would generally have a smaller notion of “regional” and “local” – a more provincial concept of place hierarchy, if you’ll excuse the pun. If not, the workaround could always be to genericize the labels even further: “International border” for admin_level=2, “Subnational administrative boundary” for everything else.
I would think “regional” in the context of a small country could likely include areas beyond the national borders, and “local” could mean the whole country. These terms are assuming different meaning according to context. In the extreme, for the Vatican City (0.5sqkm) one would expect “local” to mean in Rome, which is more than just the national territory – rather than splitting the territory into ever smaller pieces, in tendency there will be less levels of hierarchy in smaller countries.
Vatican City might be a poor example, since it has no administrative subdivisions, just the international border that I would label as such. However, you’re right that other small countries like Andorra, San Marino, Luxembourg, Hong Kong, and Singapore shouldn’t be required to tag their first-order subdivisions as admin_level=6 or higher, as they do now, just because everything inside the country is local and there isn’t as much need for hierarchy.
At this point, maybe leaving all the subnational boundaries undifferentiated would help us coalesce around fewer than a dozen keys to indicate the formal designation of a boundary’s jurisdiction…
Luxembourg doesn’t match the other countries in this list. It’s no microstate but covers a considerable area comparable to the Saarland, the smallest territorial state in Germany, which is divided into six counties. It is appropriate that admin_level=6 is used for the cantons of Luxembourg. Example: Relation: Canton Grevenmacher (407796) | OpenStreetMap
Circling Luxembourg is a nice round trip of about 300 km and you’ve got to be a bit trained to do it with your bicycle in just one day (the same goes for the Saarland).
In the absence of an easily usable table with country specific names, I would suggest simply using the numbers.
BTW I would consider size discussions a distraction, for example US states, German Bundesländer and Swiss cantons enjoy roughly the same amount of autonomy from their parent federal body and provide the same level of “administration” even though they can easily be order of magnitudes different in size.
Right, I get the impression that the smaller countries I listed have chosen to start at 6 or so out of concern that data consumers would otherwise give level 4 boundaries the same prominence as the much larger subdivisions of larger countries, or would literally label them as states, as osm-website does. But as far as I can tell, this shouldn’t be so much of a concern, because it’s up to data consumers to figure out that some countries’ subdivisions are larger or smaller than others’.
This is a possibility too. It could be somewhat confusing because of the skip-level convention that most countries follow. Outside of OSM, “second-level subdivision” is a real term, but it usually corresponds to admin_level=6 in OSM. Maybe putting it in quotation marks would help? “Level ‘6’ administrative boundary”?
I’d still hope for us to eventually coalesce around country-specific names that are data-driven, but anything would be an improvement over the current labels.
A more machine readable table akin to the one for speed limits wouldn’t be Too hard to devise for simple text strings I believe.
How easy that would be to then plug in to osm.org I don’t really know. Absent that, simply the numbers are better than the current Frankenstein naming.
This table is about inferences that a router can make in the absence of explicit speed limit tags, whereas the problem here is that the explicit tags are orthogonal to what users (and mappers) expect to see on screen. A table based solely on admin_level=* and countries wouldn’t really work, because many countries assign multiple legal designations to the same admin_level=* value. For example, some countries use admin_level=6 for provinces, centrally administered cities, and unincorporated territories.
A better solution would be another key that indicates the legal designation, regardless of its nesting level. For localization purposes, the values would ideally be keywords, which can be translated like any other software string. There would be no need to maintain a separate table.
One complication is that words can have multiple meanings, so some languages translate them variously. For example, depending on the country, Vietnamese translates “province” as either tỉnh or tỉnh bang, “state” as either bang or tiểu bang, and “town” as either thị xã or xã. Of the existing schemes, admin_type:PH=* and official_status=ru:* allow data consumers to easily look up the translations appropriate to a particular country, while designation=* and border_type=* require the data consumer to perform a spatial query to determine the country that the boundary lies within.
I would caution against blanket assumptions about administrative level complexity! In lots of non-federal countries, the administrative units are pretty uniform and don’t really have variations in naming or duties.
Barring that, a separate key is pretty useful (and perhaps inevitable) in jurisdictions where this isn’t the case.
Enough countries lack a one-to-one correspondence between admin_level=* and legal designations – including many non-federal countries – that a simple table by country wouldn’t be a significant improvement over just using numbers. By decoupling the levels from designations and adopting a secondary key for this information, the countries that have more uniform designations would need to endure some seemingly redundant tagging, but this would also be a more data-driven solution that data consumers could take up more readily. (So far, the speed limit defaults table is hardly used at all by routers, despite Herculean efforts.)
Regardless, this may be escaping into a much greater convo of what we need to do about andministrative boundaries and legal jurisdiction tagging in general, which would probably be a pretty global undertaking by definition.
My intention when opening this thread was to more narrowly focus on the naming scheme in OSM.org, that also happens to try to solve this somewhat poorly.
I think it preferable to revert to something more generic rather than keep this placeholder until a more suitable and nuanced replacement is provided.
If you wouldn’t mind opening an issue in the openstreetmap-website issue tracker on GitHub, that would make it easier for me or someone else to justify the pull request to change the nomenclature. So far it’s just me rocking the boat.
