Talk:Tag:boundary=administrative

Discuss Tag:boundary=administrative here:

---

Albania

As seen in Wikipedia's Municipalities of Albania, in 2015 Albania has merged the existing 373 municipalities used in OpenStreetMap to date into 61 new municipalities.

I have contacted INSTAT.gov.al for further insights and some discrepancies outlined in the Wikipedia Talk Page. Also have asked for confirmation if admin-level 7 (district) has been made obsolete in the process (I assume so) and if the municipality borders have been left intact. If the districts are not obsolete, some will have to be changed as municipalities were merged.

Osm ccom (talk) 21:51, 6 September 2017 (UTC)

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 gov.scot, 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)

Shouldn't the crown dependencies be a level 3 division of the UK? Alkenrinnstet (talk) 19:31, 16 December 2017 (UTC)

No, because they are not part of the UK. They are separate self-governing territories - see https://en.wikipedia.org/wiki/Crown_dependencies --Csmale (talk) 20:27, 16 December 2017 (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)

Please keep in mind that there are automatic interpreters in the information age, not everything is interpreted by people understanding conflicting use of admin-levels. Example -- Osm ccom (talk) 21:51, 6 September 2017 (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)

For now OSM favors the separation into 3 distinct areas, putting the disputed area outside of both countries claiming it, and creaating a pseudo-entity for that area.

I think that the additional displauted area could still be included in the relation of both countries, but keeping that area as a separate relation with its own borders, as a child member of both relations for both countries. Such child member would have a role "claim". The disputed area then gets admin_level 2 as if it was a normal separate country.

So suppose that country A claims {A,B} and country C claims {B,C}, the country A has only the borders of its undisputed areas, excluding B (same thing about country C).

Now comes the problem of the "defacto" boundary: in this case, where it exists (the central black line) above: that de facto border should be used by both countries in their own relation. And the two separated claimed parts would be two distinct boundary objects.

So suppose that country A claims {A,B,C}, but has defacto control only on {A,B}, and country D claims {B,C,D} then its "outer" borders will include only {C,D}; the two areas B and C will have their own objects (not with admin_level 2, and only the common defacto border between B and C will have admin_level 2 but with the additionbal tag "defacto=yes", the other borders would have admin_level 2 but with an additional tag "disputed=yes", allowing renderers to represent dotted patterns instead of a continuous line; the same technic could be used for boundaries that are estimated/undetermined/fuzzy with "fuzzy=yes", such as the border of Arab Emirates where the border across the desert is not formally known where they are above some distance from populated areas and official roads).

Other cases also exist where a part is co-administered by a full agreement between tow countries. They are "codominions" such as the border between Luxembourg and Germany, or a small island between France and Spain whose administration legally changes every 6 months. It's impossible to day that there's a "defacto" line splitting that part in two (it would not even bee a correct estimation). Isolating this area from both countries is a better solution.

The general idea being that we should not tolerate that entities of the same kind in OSM are overlapping each other, but that this does not mean that one country must take the control completely over the other one.

There are still some more complex exceptions where an area is defacto and effectively fully in control of a given country (and enforced) even if another country claims it as its extension (we have the case with new insular possessions of China, invading the territory of countries that China had recognized, thus in full violatation of international treaties that were ratified by China and confirmed by other countries and the UN council, with China previously also recognizing the other country that had full legacl ownership of their territory; then came the Chinese People's Republic, but its authority was formally transfered to P.R.China only on territories that it fully controled, and that were also recognized by the former Republic of China established now in the State of Taiwan: P.R.China aurgues using some old unratified conventions at a time where P.R.China did not even exist and was another regime that had recognized the corders of the neighbours; this is a complex case where only defacto exists but where OSM should not accept to represent it as its full ownership. This could only be a "de facto" border, represetned as a dotted line versus a continuous line and the Philippines integrity should be respected because China also claims its respect to territorial integrities of recognized countries). — Verdy_p ^(talk) 14:44, 7 September 2017 (UTC)

Crimea

There is also areas like Crimea generating computing errors as they are being duplicate in OSM. Check out Ukraine on that example site (I like a lot) and select levels 2 and 4, then have a look at the Crimea. Only Sevastopol being part of the Ukraine on level 4, but all Crimea on level 2. Then select Russian Federation, South federal district (level 3) and all child levels. Interesting, on OSM, we have the same regions for both countries. Only Sevastopol as a former Russian exclave seems to be "undisputed". It is not contemporary to have such conflicts in a data-driven environment, not until we can have Zero and One complemented by a "maybe".

Example in OSM: Bakhchysarai Raion is part of Republic of Crimea (as subarea) plus Autonomous Republic of Crimea (as subarea) - Result, map conflict!

Osm ccom (talk) 21:51, 6 September 2017 (UTC)

Land Parcels/Cadastre Boundaries by Higher Level Numbers

Individual parcels of land need sometimes to be mapped. The boundaries of these lots are described in the cadastre, land register or register of real estate. The governmental and administrative sections finallyin some countries end at those boundaries. So boundary=administrative + admin_level=* offers a good way to map this data.

The admin_level=13 is appropriate for the final parcels of land described by the cadastre. Such parcels or lots have an individual owner. Please check if OSM may use cadastral boundaries (Example: France).

A structure for Germany would be:

• Land areas around villages, districts, parishes, Gemarkungen could be mapped with admin_level=11. These cadastral districts were created in the first complete land survey Urvermessung in the 19th century. They are still the base of the German land register. And they give a good view of the time before the big villages harvested the smaller ones in acts like Gebietsreform.
• The admin_level=12 is needed for subdistricts of Gemarkungen called Flur. They exist only in some federal states (Not in Bavaria).
• With admin_level=13 individual parcels, Flurstücke could be mapped. Ownership data should not be included in OSM.

--Hb 10:38, 10 February 2020 (UTC), redacted on 25 February

But are they administrative units? Or do they have other functions such as electoral? If they have no administrative meaning (elected or apointed administration, etc.) than maybe boundary=political if electoral functions, or boundary=postal_code if purely addressal boundaries. Adding additional admin_level=* should not be necessary. --Skippern (talk) 10:50, 10 February 2020 (UTC)

Yes, they are target units for the fine grained administration. The right to plow the land or not, the right to build a house or not is given to a lot. Electoral boundaries are based on admin_levels 8 and above in Germany. Postal code regions are maintained by a private postal company. Adding additional levels to mainstream editors or rendering levels 11 and below is not necessary. The levels 12 and 13 may have some use when mapping issues need to be solved. --Hb 18:48, 10 February 2020 (UTC)

I strongly disagree with mapping land ownership boundaries as boundary=administrative. These boundaries are not administrative like the boundary of a province, county or municipality: they do not have different laws or administrative rules or different leadership. Some mappers have used other tags like boundary=lot for this purpose, though I would not add this data to Openstreetmap at all: if the data is freely available from the government, then database users should download it directly from that more reliable source. --Jeisenbe (talk) 06:08, 13 February 2020 (UTC)

Land ownership data is not needed in OSM and not topic of this discussion. It is about admin_level values. As said, the German administration uses cadastral boundaries (admin_level=13 or boundary=lot) as base to form the larger administrative units. A lot can not be splitted by an administrative boundary here. And I doubt that this is possible in other states. So that boundary can be subject to other laws, rules and leadership. --Hb 12:44, 14 February 2020 (UTC)

In the United States, Canada, Indonesia, Mexico and most likely in some other countries it is certainly possible for a certain plot of land to cross over the boundary of a municipality or even a State or Province. But even if land parcels are not divided between administrative areas in your country, this does not make them administrative entites. --Jeisenbe (talk) 06:02, 15 February 2020 (UTC)

Result: boundary=lot and boundary=cadastral are more useful to tag cadastral data. ----Hb 17:40, 25 February 2020 (UTC)

The decision about whether a feature is appropriate for the Openstreetmap database is not only about utility, but about verifiability. Please see arguments against mapping cadastral boundaries, summarised in the warning boxes at the page for Tag:place=plot. Also note that the more common ways that such cadastral boundaries have been imported is with place=plot or boundary=lot --Jeisenbe (talk) 04:49, 26 February 2020 (UTC)

Explicitly describe tags on ways as optional and relation tagging as recommended?

I think that it would be save to describe

• Tagging relation containing ways without boundary tags as OK
• Tagging relation containing ways with repeated boundary tags as acceptable, but not necessary or recommended
• Tagging without relation, solely by tagging ways as not recommended and obsolete
• Tagging relation containing ways with repeated administrative=boundary tags without admin_level=* as pointless as inferior to both versions

Mateusz Konieczny (talk) 09:27, 5 February 2021 (UTC)

I agree with you on the substance, but I think that's too big a change to make with a silent wiki edit. I've drafted a proposal to do exactly this, but I've been too backlogged with my other proposals to put it forward so far. Feel free to take it over if you like. --ZeLonewolf (talk) 13:56, 5 February 2021 (UTC)

I plan to do it via tagging mailing list if wiki talk page + long time is not sufficient (I planned to wait 3 months or something similar), I see no need for proposal here. (hopefully I am not wrong). But big parts of your proposal will be definitely useful, thanks! Mateusz Konieczny (talk) 13:59, 5 February 2021 (UTC)

See also Talk:ÖPNVKarte#Boundaries_tagged_as_relation_only_are_not_shown Mateusz Konieczny (talk) 14:13, 5 February 2021 (UTC)

Cquest (talk) 11:20, 9 February 2021 (UTC)

A very large proportion of ways actually DO have these tags (1.2 million ways !). Data consumers may have used this fact (this is my case). Such a change needs more publicity than just a couple of email on the tagging mailing list between 3 persons so that a consensus is found and all effects taken into account prior to change tagging recommendations. (unsigned comment by Cquest)

FYI, I'm using the boundary tag on ways in combination with maritime=yes to render boundaries differently on land and sea. (unsigned comment by Cquest)

"boundary tag on ways in combination with maritime=yes" - supporting this by tagging recommendations was broadly rejected, when proposed some time ago by OSM Carto authors (I can try tracking down this thread if you want) Mateusz Konieczny (talk) 11:42, 9 February 2021 (UTC)

That is incorrect. @Imagico: rejected to only rendering based on the ways, but he uses the ways + maritime=yes to render maritime boundaries differently in his own map styles. See https://github.com/imagico/osm-carto-alternative-colors/blob/alternative-colors/admin.mss#L20 - we could use this information at OpenStreetMap Carto for maritime boundaries only, as long as we don't stop rendering the main relations for the boundaries on land. This is another way to do this, but it required using comp-op techniques and is more technically challenging. --Jeisenbe (talk) 16:56, 11 February 2021 (UTC)

@Jeisenbe: I was thinking about https://lists.openstreetmap.org/pipermail/tagging/2018-March/thread.html#35347 https://github.com/gravitystorm/openstreetmap-carto/pull/3102 that I interpret as rejecting requirement of tagging admin_level=* on ways Mateusz Konieczny (talk) 18:57, 18 February 2021 (UTC)

"boundary tag on ways in combination with maritime=yes" - in which map style? It would be useful to document that. Is it technically feasible to take maritime=yes from ways and other data from relations? Mateusz Konieczny (talk) 11:42, 9 February 2021 (UTC)

The style mentioned by Christian is https://github.com/cquest/osmfr-cartocss/, visible on http://tile.openstreetmap.fr. --Nospam2005 (talk) 20:14, 9 February 2021 (UTC)

"A very large proportion of ways actually DO have these tags (1.2 million ways !)" - it is not surprising as this is the original tagging schema. Mateusz Konieczny (talk) 11:39, 9 February 2021 (UTC)

"between 3 persons" - on tagging mailing list lack of protests, nitpicking and complaints is typically indicator of something utterly unimportant (unlikely here) or of a support. If you are opposed to that - feel free to comment there (or just here - I am not sure whatever you think that I should do also something else before editing Wiki but you are not opposed, or are you outright opposed) Mateusz Konieczny (talk) 11:39, 9 February 2021 (UTC)

"needs more publicity" - what would you propose to do? Mateusz Konieczny (talk) 11:39, 9 February 2021 (UTC)

boundary defined by the current state of a river : Gluing or split ?

The last improvement said that gluing is ok when boundary defined by the current state of a river. Indeed it's not wrong in this case. But shouldn't it be recommended to cut the relation to use the river directly instead of having 2 ways on top of each other often over a long distance ? Marc marc (talk) 18:33, 14 March 2021 (UTC)

I would say that it is probably preferable, though I would also consider it as "gluing" though in a different way. Mateusz Konieczny (talk) 20:09, 14 March 2021 (UTC)

admin_level system in India is problemetic.

Many of the Indian states are subdivided into divisions. However, admin_level of division is 2 and admin_level of state is 3. Gwahak (talk) 13:47, 2 October 2021 (UTC)