From OpenStreetMap Wiki
Jump to: navigation, search

Discuss Tag:boundary=administrative here:

United Kingdom

The ONS created a geoportal at - whereas we found the 2014 boundaries for England/Wales matching Eurostat 2015 LAU2. Scotland does not match and they use "Data Zones" anyway, not the "ward level" defined by ONS. According to, the ward/LAU2 are "aproximates" for data. As such, it might be interesting to define LAU2 level as admin level 8 for UK, using Admin Level 9 as "Data Zones"?

However, the current OSM admin levels do not compute with ONS/Eurostat so it might be an idea to update U.K. definitions?

Admin Level 8 should reflect LAU2, level 7 LAU1, level 6 NUTS3, level 5 NUTS 2 - so I'd suggest Scottish level 4 for the Intermediate Zones?

--OSM ccom (talk) 07:23, 27 May 2016 (UTC)

I would suggest keeping statistical hierarchies separate from administrative hierarchies. It is tempting to conflate the two, as they may share borders in many cases, but there is no element of "administration" (i.e. (local) government) involved in the NUTS areas. Not all UK NUTS boundaries are coincident with administrative boundaries - as you mention, in Scotland some large council areas are split/spread over NUTS areas.

Relations with type=boundary, boundary=statistical would seem to be appropriate. Something along those lines may already be in use, I haven't checked. That would create a parallel hierarchy, and keep the concepts separate. A tag like "stats_level:nuts=4" or whatever would structure the content of the hierarchy. --Csmale (talk) 07:59, 27 May 2016 (UTC)

Admin Level 8 (Eurostat LAU2) correct data

We also had to override Croatia¹, Denmark², Portugal and Romania for Eurostat LAU2 association. It might be good if someone maintaining those countries boundaries could contact those sources to adopt that data quality officially in OSM?

¹ Croatia files received after inquiry by mail

² Deep link requires a user login

Side note: Just to mention it, we have our solutions and approvals for our site. This is just to direct OSM to potentially helpful sources. I only use this data, I would not know how to make it "properly" available in OSM.

--OSM ccom (talk) 07:23, 27 May 2016 (UTC)

admin_value=? for landuse zone boundaries

The table of admin values for Australia doesn't have a value for boundaries of landuse zones.

In Australia, landuse zones can be set at national, state and local government levels. I'm unsure which admin_value to use to indicate the level of government that has jurisdiction over that boundary. The table entries doesn't seem to fit. For instance, a state government landuse zone of 'state forest' might be a smaller area than a suburb. It would look odd if the boundary admin_value was that of a state boundary.

Any suggestions?

admin_value=11 . That's just silly

erm... Tag:boundary=administrative#11 admin level values for specific countries That's a joke right? We invent an entirely arbitrary scale measure (something which is very rare in OpenStreetMap tagging, but it was a welcome resolution to endless discussions about admin levels in the early days) It has values from 1 to 10. Ten different levels, because that's enough to cover everything right?

But no. Oh no that's not enough for some countries. They just had to turn it up to 11. Tell me this is a joke spinal tap reference and people aren't actually using this silly tag.

-- Harry Wood 19:16, 3 September 2012 (BST)

+1 -- In Brazil we had two short discussions regarding more admin levels (we have used all levels from 2 (national border) to 10 (bairro/suburb) and I tried to squeeze in a district (admin_level 9) and subdistrict (also admin_level 9) in between municipality (admin_level 8) and bairro (admin_level 10), solution became border_type=*. Similarly one user in Rio de Janeiro started mapping borders of sub-bairros (administrative division of bairro) but can't remember how that one was solved. --Skippern 23:52, 3 September 2012 (BST)
Using the same level for districts and subdistricts is likely to make Nominatim choose either at random when generating an address line, instead of showing both as one would expect. Strictly, beyond city-level (level 8), only districts (level 9), subdistricts (undefined) and neighbourhoods (called "bairros", level 10) can have some degree of "administrative autonomy" in Brazil. Maybe that's irrelevant, since Brazilian regions (level 3), mesoregions (level 5), metropolitan areas (level 6) and microregions (level 7) also don't. Brasília, which uses a block addressing system (much like Japan), requires at least one extra division (for "quartiers") of its "sectors" (which can be made equivalent to "neighborhoods" or "bairros", although they do not have administrative autonomy) to fully express address lines and allow proper address lookup. I've felt the same need in my hometown, Porto Alegre, where one specific planned neighbourhood requires another two levels of subdivision ("sectors", then "quartiers"), both affecting address lookup. A scheme to support all of these combinations would require another 3 levels (thus pushing the current limit of 10 to 13) and would shift Brazilian neighbourhoods to level 11, probably breaking compatibility with current apps. We could do away with levels 5 to 7 (as they're not used in addresses and are not independently administrated), but then making cities level 5 would break compatibility with the rest of the world. --Fernando Trebien (talk) 20:26, 23 December 2013 (UTC)

Well I think we should delete that section. I sense some people may disagree. Labelling it for deletion now. -- Harry Wood (talk) 16:38, 6 February 2013 (UTC)

I disagree. Proposing it for deletion won't stop it from being used by people who have need of it. --seav (talk) 17:19, 6 February 2013 (UTC)
I agree, solution can be found different than just adding more levels, for example by using border_type=* --Skippern (talk) 21:04, 6 February 2013 (UTC)
Bad idea. In NL and DE the model is already documented to level 11, and it would be not illegitimate to extend it to 12 either. The model should fit reality, and if it doesn't, it's a bad model. I thought tagging freedom was thought to be a fundamental principle of OSM. --Csmale (talk) 15:16, 7 February 2013 (UTC)
What do you propose as the new admin_levels for neighborhoods in NL? We already use the scheme as documented, I'm not in favor of deleting that section without first determining how the boundaries in NL should be reclassified. Nor do I look forward to changing all the existing relations, or will you change those for us? -- Sebastic, Mon Feb 18 20:08:09 UTC 2013
Just to be clear (in case user Sebastic is talking to me!) - I am not proposing any change for NL, merely pointing out that neighbourhoods (wijken) at admin_level=11 are frequently subdivided by the municipality into "buurten" - with properly documented (although sometimes poorly publicised) boundaries. If anyone wants to put "buurten" into OSM, admin_level=12 would be an obvious candidate.--Csmale (talk) 15:03, 19 February 2013 (UTC)
I was directing my question to Harry Wood who is the one that wants to delete documentation for an actively used feature. I care about boundaries since I'm working on getting all settlement boundaries (admin_level=10) boundaries into OSM using the BAG open data the Dutch government provides. Restricting the admin_levels to 10 like all others, except Germany, would imply having to remove the already existing admin_level=11 boundaries. Since deleting useful data is not likely the intention, it would entail renumbering the boundaries in NL to fit within a 10 level scheme. Neither option appeals to me, because it causes unnecessary work for our already limited contributor base. Of which none care about, or consider themselves able to do boundary work. But if for the sake of global consistency the admin_levels need to be harmonized, I'd like to hear some good arguments for it. And if possible I would like the person who pushes a change to do the work, and not create an undesired burden of work for the local community. It may be good to rethink the admin_levels for NL, The Kingdom of The Netherlands does not use admin_level=1 as documented on the Wiki, but admin_level=3 for some, to me, unknown reason. So there is room for improvement, but I'm not looking forward to changes just because other countries work differently. I suspect, as I wasn't involved in OSM back then, the Dutch chose to use the 11 levels to stay close to our German neighbors, something we've done for centuries. But this, like change for change sake, is no reason to stick to it. I'm open to constructive debate on how to harmonize the admin_levels worldwide, if it's possible to get agreement on that. Which is something I doubt. Therefor I would like to keep what we have now, since it's in active use. And changes to the model would force work upon us to support them, without a clear benefit. -- Sebastic, Tue Feb 19 15:50:49 UTC 2013
Skipping numbers just to add admin_level=11 indicates that an upwards shift is needed, restructuring the definitions, like clearly is the case in Germany. On the other hand, if there is a clearly documented set of admin levels (with clear meaning of administrative level, not just some political subdivision), than the topic is different. Currently, I have not seen any reason for actually adding these as administrative boundaries, as they have as far as I can see different purposes. I am not saying that these borders should not be added to the database, but maybe consider using border_type=*, boundary=political, boundary=civil or something that actually describes what it is. What administrative purpose do a "buurten" have in NL? Do they have an elected representant in the city parlament, do they have the responsebility to plan maintenance of roads, or are they responsable for the safety of school access? If it is just a practical or political subdivision that looks great on paper than the answer is probably to put the border in a different category. An example I can take is the city where I live. The city of Guarapari have 3 district subdivisions on admin_level=9, but no suburb/bairro subdivision on admin_level=10 as many of the surrounding municipalities. Why? Because there are no defined borders, and the city council see no need in defining these borders as it doesn't give any change to the administration of the city. The various bairros (suburb) is a postal and point of reference division only, though the neighbouring Vila Vela may be have more sub tasks defined for its bairros. --Skippern (talk) 16:28, 19 February 2013 (UTC)
Using a different tag just to avoid having to increase the admin_levels doesn't make sense to me. It breaks the scaling the admin_levels provide. Boundaries at level N are a subdivision of lesser levels. We can keep scaling this to smaller subdivisions until we reach MAXINT.
The Dutch Central Bureau of Statistics (CBS) keeps track of "wijken" (districts) en "buurten" (neighborhoods), it defines a "wijk" (district) as:
"Part of a municipality in which a certain type of land use or cultivation predominates. For example: industrial, residential high-rise or low rise. A district consists of one or several neighborhoods."
The CBS defines a "buurt" (neighborhood) as:
"Part of a municipality, which from construction standpoint or socio-economic structure is homogeneous delineated.
Homogeneous means that one function is dominant, eg residential (residential area), work function (industrial area) or recreational function (nature). A mix of functions may also occur.
The municipalities in the Netherlands are divided into districts and neighborhoods. Neighborhoods are the lowest regional level. Districts are summations of one or more contiguous neighborhoods. The municipality determines the division into districts and neighborhoods. The CBS coordinates this format nationwide."
The quoted text is a translation from the Dutch definitions, which is a bit confusing since the wiki talks about wijk=neighborhood whereas CBS talks about buurt=neighborhood. The important thing is the structure of the subdivisions.
Since our admin_level=11 boundaries are subdivisions of the municipality boundaries, using a higher admin_level instead of a different tags seems correct. The reason we need admin_levels higher than 10 is because we synced our woonplaatsen (admin_level=10) with the Germans, to as closely match their definition as possible (source), but since we do have subdivision of those we need admin_level=11 and up.
Before the admin_level=11 documentation is deleted I think it's wise to bring this discussion to the wider Dutch and Germany communities to get the input of those who don't monitor the wiki talk pages. -- Sebastic, Tue Feb 19 19:23:13 UTC 2013
OK *sigh*. Clearly it's going to be a pain to move from using admin_level=11 in these places where people have been doing it for a long time, so that's a shame isn't it. Somebody started using a silly tag and for some reason lots of people followed, and nobody voiced the fact that it was a silly tag at an early stage. Now we're stuck with it.
Reminder for those that need it: Why is it a silly tag? Because... it's a number from 1 to 10! It's sort of baked into the very simple concept, the way this tag is conceived, that you don't just start turning it up to 11. I honestly think the first person to do an admin_level=11 must have just been joking around making spinal tap reference.
So question... Can anyone think of something we could we say in the documentation here, which would discourage people from adopting this tag in more countries, while not particularly requiring people to rework their existing tagging?
-- Harry Wood (talk) 11:10, 17 July 2014 (UTC)
I think you are about the only one who has a real problem with this tag value. The nominatim developpers certainly didn't cause a stink about it. It just works. Since it just works, there is no reason not to use it elsewhere.
On top of that. The proposed "solution" of shifting everything up into the gaps doesn't work either. We started out using only the even numbers, so we could fit "unusual" stuff in between. Not so we could shift everything to completely different levels. Generic tools that don't implement this complete table, should be able to still assume that the obvious admin levels are still at those numbers. So national boundaries at 2, the traditional subdivision at 4 and 6 (two levels so we can deal with federations) and municipalities and the like at 8. If you want to divide the municipalities into more than two levels, there is only one direction to go: Past number 10.
Do you have any real arguments why people shouldn't use values above ten? Whether you personally think something is silly shouldn't really matter to anybody else, if you can't give solid arguments for this conviction. E.g. does anything break when people use this tag? --Cartinus (talk) 06:25, 19 July 2014 (UTC)
I agree with Cartinus. OpenStreetMap uses a free tagging system, and there is nothing to worry about an admin_level tag above 10. We assigned even numbers on the traditional administrative divisions (2=country, 4=state/province, 6=counties/districts 8-9=municipalities 10+=divisions of municipalities). But divisions of countries may vary, and the admin level tags may mean another division. For example, in my country, the Philippines, the admin levels assigned per division is this:
  • 2=country*
  • 3=regions
  • 4=province
  • 6=city/municipality
  • 8=administrative district
  • 10=barangay
On those gaps, these are included
  • 5=provincial board districts
  • 7=city/municipal legislative districts
  • 9=barangay zones
Above admin level 10, these are included
  • Sitio/purok (admin level 10)
There are several divisions that cannot be accommodated by the default tagging, like this divisions in the Philippines, the sitios and puroks, and OpenStreetMap's free tagging system allows us to add an admin level tag above the default 10 levels. Harry Wood, there is nothing wrong about having an admin level above 10.--TagaSanPedroAko (talk) 11:32, 9 June 2016 (UTC)

Disputed borders

Point of view of Blue state: border is ABCDEF, point of view of Red state: border is ABGHEF, de-facto border: ABEF, disputed territory: GBCDEH

Are there any opinions about situations, when borders of states are disputed? For example, there are two states, which have border between them. One state thinks, that border is located on one line, second state thinks, that border is located on second line. De-facto border, which is defined by de-facto control of states, is located on third line. How can we map lines AB, BCDE, EF, BGHE, BE? How can we map disputed territory GBCDEH? How can we map borders, which exist only in imagination of one state? How can we map borders, which exist in imagination of one state and coincide with de-facto border? How can we map border, which exists in reality, but is not recognized by both adjoining states? What multipolygon should we use for outer border of state: official border, which is defined by laws of this state, or de-facto border, which is defined by de-facto control of government/army of state? Dinamik 10:46, 25 November 2012 (UTC)

My idea is to replace the use of 'inner', 'outer' (and the deprecated 'exclave', and 'enclave') roles in a type=boundary relation with 'defacto' and 'dejure' (or 'claimed') roles. The 'inner' and 'outer' roles are very trivial to compute (assuming a relation is properly constructed) and are actually redundant information.
As an example, let's take the wikipedia:McMahon Line. For the Indian boundary relation, the McMahon Line is 'dejure' and 'defacto', so this line will be tagged as 'dejure'. For the Chinese boundary relation, the McMahon Line which is part of the wikipedia:Actual Line of Control is tagged as 'defacto' while the claimed border south of the McMahon line is tagged as 'dejure'. --seav 21:01, 25 November 2012 (UTC)

Another example is the Abyei region: Here the area is currently covered by the relations for both countries. So in terms of the image the relation for red would include ABGHEF and the blue relation ABCDEF. I think this is the easiest way of handling the situation with today's means. --Ohr 12:20, 26 November 2012 (UTC)
Changing the inner/outer roles logic (shared with multipolygons) would probably break all current apps out there. I think disputed areas should not belong to either country and be a separate entity. Then, they would be mapped as independent regions (maybe with admin_level=2, maybe with place=region, or both) and those regions may be added to their claimers assuming the role "claimed". This way, we don't change the logic of multipolygons and addresses would be searched for and displayed in a neutral form (possibly indicating that area is disputed) using current technology. It's also easier to navigate back an forth in the relations to find such disputed areas (with any editor, and also using the main website's UI). This would work as well for claimed but not effectively "disputed" areas such as Antarctic territories. Disputed territories are the exception, not the norm, I don't think we need to make established rules more complex if we can work around them like this. --Fernando Trebien (talk) 20:54, 23 December 2013 (UTC)