Hi all, Please all, take a very attentive look at this. Please note the subject change: unnecessary. Please note the disambiguation boundary vs borderline.
The problem with admin_level tags is that numbers need to exist to *be **able* to nest boundaries and hence that only administrative boundaries are nestable. That problem does not exist with subarea relation roles which: * can do the nesting without any sort of level number, including none, and with any boundary type * can even nest one boundary type such as administrative inside another such as political to avoid duplicating identical trees of two types * hence make never-ending discussions unnecessary about which numbers to use or how to insert a level between 6 and 7; levels can and should be replaced by names such as "province" and "district" with the result that a map can tell (name) "province Liège" from "arrondissement Liège" (and "city Liège") * are much more explicit than levels (plain list of provinces instead of having to discover them by level) * can easily cross-check subareas with existing levels, and would probably easily find level mistakes * similarly, could easily be *generated* from existing levels * are much more easier to design and tag, I can tell * to answer a frequent duplication criticism: o they certainly duplicate less than a myriad of cases like boundary Belgium <https://www.openstreetmap.org/relation/52411> and place Belgium <https://www.openstreetmap.org/node/1684793666> (that should be identical and are certainly different), and other uncriticized duplications o it's not really duplication if the form is so different o and if both subareas and levels existed everywhere and we got accustomed to subareas, I wonder which we would find superfluous Notorious cases of subareas are * "ceremonial" Berkshire <https://www.openstreetmap.org/relation/52411> that is not administrative, has no level and yet contains administrative "councils" Berkshire itself, however, is not a subarea of a higher level but it could o Relation Bracknell Forest (113682) <https://www.openstreetmap.org/relation/113682> as subarea o Relation Reading (115074) <https://www.openstreetmap.org/relation/115074> as subarea o Relation Slough (117097) <https://www.openstreetmap.org/relation/117097> as subarea o Relation West Berkshire (116938) <https://www.openstreetmap.org/relation/116938> as subarea o Relation Windsor and Maidenhead (111014) <https://www.openstreetmap.org/relation/111014> as subarea o Relation Wokingham (114311) <https://www.openstreetmap.org/relation/114311> as subarea * Belgium <https://www.openstreetmap.org/relation/52411> is the top of two boundary subtrees that share much of the same lower subtrees: o administrative + Relation Flanders (53134) <https://www.openstreetmap.org/relation/53134> as subarea + Relation Brussels-Capital (54094) <https://www.openstreetmap.org/relation/54094> as subarea + Relation Wallonia (90348) <https://www.openstreetmap.org/relation/90348> as subarea o political, which is linguistic administration + Relation Flemish Community (53136) <https://www.openstreetmap.org/relation/53136> as subarea + Relation French Community (78967) <https://www.openstreetmap.org/relation/78967> as subarea + Relation German-speaking Community (2425209) <https://www.openstreetmap.org/relation/2425209> as subarea * multilingual Switzerland would be another good candidate There should be a "language" type of boundaries and the second Belgian subtree could be of that type. For fast and easy navigation, there should be a "parent" role for a boundary relation to indicate the tree(s) under which it belongs. And also some manner for the borderline ways to indicate all the boundaries that they belong to, at least the top one. I'm not going to go into that, but, in theory, subareas make the "outer way" roles unnecessary for higher boundaries of the tree. I think it's always true that the borderline of a level is the sum of the borderline ways of all the levels below it from which the ways that appear twice are eliminated. The process, however, is recursive, long for top levels like a country. It needs accessing all its borderline pieces, both external and internal. While that sometimes stated remark is true, it's better to use a utility that does that process at tagging time. That process is also at the core of a boundary consistency check, such as being closed etc. In a first phase, the subareas could be generated by an automatic process. In a second phase the level based nesting could be automatically derived from the subareas. Thanks for your attention, Cheers André. On 2018-03-10 01:51, Matthijs Melissen wrote: > Hi all, > > OpenStreetMap Carto, the default stylesheet on openstreetmap.org, is > considering to change the mechanism for rendering admin boundaries. > The proposed rendering of admin borders will be based on admin > boundary ways rather than polygons. This has a number of advantages - > for example, it will make it possible to style maritime boundaries > differently. > > The admin boundary ways are already in the database. However, in some > cases they are missing an admin_level tag. When the proposed style > change will be deployed, boundary=administrative ways without > admin_level tag will no longer be rendered. I would therefore suggest > to make sure admin_level tags are present on all > boundary=administrative ways. > > A map showing admin boundary ways without admin_level tag (displayed > in gray) can be found here: > http://product.itoworld.com/map/2?lon=20.00736&lat=51.92203&zoom=6 > As can be seen, most countries already do have admin_level on ways. > However, in for example Poland, Iran and Australia, this data seems to > be missing. > > -- Matthijs > > _______________________________________________ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging