Re: [Tagging] Tagging request: unnecessary admin_level tags

[André Pirard]

On 2018-03-11 00:37, Eugene Alvin Villar wrote:
> On Sun, Mar 11, 2018 at 12:41 AM, André Pirard
> mailto:a.pirard.pa...@gmail.com>> wrote:
>
> 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 [...]
>
>
> Subareas will not work for my country. We generally have the following
> hierarchy: region > province > city/municipality.
>
> However, we have two cases where a city inside a province is part of a
> different region from the rest of the cities and municipalities of
> that province. In this case, using admin_level=* to properly indicate
> the administrative boundaries in type=boundary +
> boundary=administrative relations is unavoidable.
Not at all.
Using an inner way role, a boundary area can have a hole in it: the hole
that your city makes in the wrong province
and that hole can be a subarea somewhere else in the tree: your city
must be a subarea of the right province.

I don't know the cities you speak of, but we have a similar case in Belgium.
Even a bit more complicated.
We use country > region > arrondissement> province > city/municipality.
Brussels capital is a city that doesn't belong to province Brabant where
it's in, not even Flanders where Brabant is.
Brussels-Capital belongs to Belgium directly as you can see in the part
of the quote that you removed.

If you look at France ,
you will see many subareas that are holes somewhere else.
>
>   * Relation Metropolitan France (1403916)
>  as subarea
>   * Relation Guadeloupe (1401835)
>  as subarea
>   * Relation Martinique (1891495)
>  as subarea
>   * Relation French Guiana (1260551)
>  as subarea
>   * Relation Réunion (1785276)
>  as subarea
>   * Relation Mayotte (1259885)
>  as subarea
>   * Relation Saint Pierre and Miquelon (3406826)
>  as subarea
>   * Relation Saint Barthélemy (537967)
>  as subarea
>   * Relation Saint Martin (1891583)
>  as subarea
>   * Relation Wallis and Futuna (3412448)
>  as subarea
>   * Relation French Polynesia (3412620)
>  as subarea
>   * Relation French Southern and Antarctic Lands (2186658)
>  as subarea
>   * Relation Clipperton Island (2573009)
>  as subarea
>   * Relation New Caledonia (3407643)
>  as subarea
>
In the north of BE there are such holes belonging to NL and even some of
those NL hole have holes belonging to BE !!!

Subareas work for everything and they are a dream. One just has to
practice and understand them.

Cheers

André.




___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging request: unnecessary admin_level tags

[Eugene Alvin Villar]

On Sun, Mar 11, 2018 at 12:41 AM, André Pirard 
wrote:

> 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 [...]
>

Subareas will not work for my country. We generally have the following
hierarchy: region > province > city/municipality.

However, we have two cases where a city inside a province is part of a
different region from the rest of the cities and municipalities of that
province. In this case, using admin_level=* to properly indicate the
administrative boundaries in type=boundary + boundary=administrative
relations is unavoidable.

~Eugene
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging request: unnecessary admin_level tags

[Kevin Kenny]

On Sat, Mar 10, 2018 at 12:16 PM, Colin Smale  wrote:

> 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")

It is incorrect even to assume that level numbers nest strictly.

In my home state of New York, we have:

2: United States
3? The Six Nations of the Haudenosaunee?
4: State of New York
5: (Reserved for New York City - a unique case in the US)
6: County
7: Township, City or Indian Reservation
8: Village, Hamlet, Ward, Community District

(1) At least one 'dependent nation' (admin_level=3?) - Akwesasne, where
the territorial claim of the Kanien'kehá:ka (Mohawk) Nation crosses
the US-Canadian border. (Currently mapped as boundary=aboriginal_lands
on the Canadian side, and not mapped on the US side.
The political situation is complicated, and there is no consensus on
the tagging.)

(2) One city promoted to admin_level=5 because it encompasses
five counties (admin_level=6), and another (which remains admin_level=7)
that has annexed some land in an adjoining county.

(3) Numerous incorporated villages (admin_level=8) that cross the
boundaries of townships (admin_level=7) - in which case the residents
owe taxes both to the village and to whatever township they reside in.

(4) Several counties and townships with indefinite borders.
(Really. The Adirondack Mountains are so remote that it's
never been worth the expense to monument the boundaries.
Nobody much cares where the county line is in a wilderness
area.)

Admin_levels are numbered for convenience but do not form
a strict hierarchy. They are useful for -
- suppressing administrative lines at a fine level that are
  coincident with the lines at a coarse level. This
  appears to be necessary for a good looking rendering.
  What is being rendered here is of course a 'borderline'
  rather than a 'boundary'.
- deciding based on zoom level or other criteria which lines
  are to be rendered ("show township lines only at zoom
  level >=12," for instance). This could be 'boundary' or
  'borderline'.

For US maps, it's really convenient to
have the level numbers, since different states have vastly
different ways to assign political divisions, and most
renderers really care only about "relative importance"
to choose how and whether to render a particular
way.

Since we already have the situation where admin_level
does not form a hierarchy in real life, no system of tagging
that presumes a strict hierarchy is going to be successful.

My personal belief of what would be easiest to both
render and query:  create multipolygons with shared
borders for administrative regions. Tag the multipolygons
with the full information for the regions; tag the ways
comprising the borders with boundary=administrative
and the admin_level of the "most important"
multipolygon.

I'm willing to be convinced otherwise.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging request: unnecessary admin_level tags

[Colin Smale]

On 2018-03-10 17:41, André Pirard wrote:

> 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")

In the UK designation=* is used (with managed, not free-text, values) to
indicate exactly what sort of admin entity it is. There can be different
entities at the same level: metropolitan, non-metropolitan districts and
London boroughs are all at level 8, and unitary authorities and
non-metropolitan counties share level 6. (The four nations all have
their own local government structures anyway). This means the name tag
can be kept pure, without having to incorporate the "function" as that
can easily be seen from the designation. 

There is a subtle difference between the area, and the local government
entity that administers it. The relationship is not always 1:1, even at
the same level. The UK is a complicated place. 

Slightly OT: Actually the UK admin levels need a bit of review. The
Regions (admin level 5) have (and have never had) no administrative
function, and there are now Combined Authorities with (limited) admin
functions spanning multiple UAs at level 6. We should convert the
Regions to something like statistical or political, and free up admin
with level 5 for the CAs. 

Colin___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging request: unnecessary admin_level tags

[Colin Smale]

On 2018-03-10 17:41, André Pirard wrote:

> * "ceremonial" Berkshire [1] 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
> 
> * Relation Bracknell Forest (113682) [2] as subarea
> * Relation Reading (115074) [3] as subarea
> * Relation Slough (117097) [4] as subarea
> * Relation West Berkshire (116938) [5] as subarea
> * Relation Windsor and Maidenhead (111014) [6] as subarea
> * Relation Wokingham (114311) [7] as subarea

In an administrative sense his is a logical error. The UAs should not be
a subarea of the ceremonial county. However in a geometrical sense it is
not wrong of course, although you could consider it redundant. 

A ceremonial county boundary is defined using a different process to
administrative counties, and in theory there can be temporary divergence
(if the admin boundary is changed by law and it takes a while for the
ceremonial county to catch up) or, indeed, permanent divergence (such as
County Durham which is split between two admin counties). 

I would be in favour of removing the subarea links in the case of the
Berkshire UAs. 

A ceremonial county has no level because it doesn't need one - there are
no ceremonial entities at a higher or lower level. 

Colin 

Links:
--
[1] https://www.openstreetmap.org/relation/52411
[2] https://www.openstreetmap.org/relation/113682
[3] https://www.openstreetmap.org/relation/115074
[4] https://www.openstreetmap.org/relation/117097
[5] https://www.openstreetmap.org/relation/116938
[6] https://www.openstreetmap.org/relation/111014
[7] https://www.openstreetmap.org/relation/114311___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging request: unnecessary admin_level tags

[André Pirard]

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 
and place Belgium
 (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
 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)
 as subarea
  o Relation Reading (115074)
 as subarea
  o Relation Slough (117097)
 as subarea
  o Relation West Berkshire (116938)
 as subarea
  o Relation Windsor and Maidenhead (111014)
 as subarea
  o Relation Wokingham (114311)
 as subarea
  * Belgium  is the top of
two boundary subtrees that share much of the same lower subtrees:
  o administrative
  + Relation Flanders (53134)
 as subarea
  + Relation Brussels-Capital (54094)
 as subarea
  + Relation Wallonia (90348)
 as subarea
  o political, which is linguistic administration
  + Relation Flemish Community (53136)
 as subarea
  + Relation French Community (78967)
 as subarea
  + Relation German-speaking Community (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