[Tagging] Tagging request: unnecessary admin_level tags

André Pirard A.Pirard.Papou at gmail.com
Sat Mar 10 16:41:11 UTC 2018


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 at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20180310/98d71983/attachment.html>


More information about the Tagging mailing list