Re: [Tagging] Tagging request: missing admin_level tags

[Erkin Alp Güney]

What is the intended usage of admin_level=0 then?


11-03-2018 01:17 tarihinde Christoph Hormann yazdı:
> On Saturday 10 March 2018, Dave F wrote:
>> I may be missing something, Christoph, but doesn't a combined search
>> for admin_level=X & maritime=yes remove any misuse of the maritime
>> tag & produced the required solution?
> Looking for ways with boundary=administrative + admin_level=2 + 
> maritime=yes will - except for the Great Lakes - get you only national 
> boundaries over the ocean.  But as pointed out this will not be 
> complete (though more complete than for land boundaries) and it would 
> not distinguish between the outer boundaries (towards the high seas) 
> and the boundaries between two countries.
>
> Looking for ways with boundary=administrative + admin_level=4 + 
> maritime=yes will get you only boundaries at the coast or over the sea 
> but it will also not cover all of them (in fact a much lower percentage 
> than for admin_level=2) and it will also not distinguish between 
> boundaries at or near the coastline and those away from the coastline.
>
Yours, faithfully
Erkin Alp

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

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
> > 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: missing admin_level tags

[Matthijs Melissen]

On 10 March 2018 at 01:51, Matthijs Melissen  wrote:
> 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.

Hi all,

Thank you all for all feedback. I will take this back to the project.

Just something I'd like to clarify: many of you seem to assume this
introduces a new tagging paradigm. The opposite is true: the proposal
uses a tagging scheme that is already used in about 90 percent of the
countries, and the retagging request only concerns the exceptions. You
might or might not agree with this tagging scheme, but it is the way
things are currently done in most countries.

I would also like to point out that other data consumers do rely on
the presence of admin_level on boundary ways too. For example,
https://www.öpnvkarte.de and https://korona.geog.uni-heidelberg.de/
already rely on admin_level tagging on boundaries (and thus do not
display internal admin boundaries in Poland). There might be more of
them.

Anyway, as I said, I will take this back to the project and will let
you know if there is news.

— Matthijs

___
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: missing admin_level tags

[Christoph Hormann]

On Saturday 10 March 2018, Dave F wrote:
>
> I may be missing something, Christoph, but doesn't a combined search
> for admin_level=X & maritime=yes remove any misuse of the maritime
> tag & produced the required solution?

Looking for ways with boundary=administrative + admin_level=2 + 
maritime=yes will - except for the Great Lakes - get you only national 
boundaries over the ocean.  But as pointed out this will not be 
complete (though more complete than for land boundaries) and it would 
not distinguish between the outer boundaries (towards the high seas) 
and the boundaries between two countries.

Looking for ways with boundary=administrative + admin_level=4 + 
maritime=yes will get you only boundaries at the coast or over the sea 
but it will also not cover all of them (in fact a much lower percentage 
than for admin_level=2) and it will also not distinguish between 
boundaries at or near the coastline and those away from the coastline.

-- 
Christoph Hormann
http://www.imagico.de/

___
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: missing admin_level tags

[Dave F]

Thanks to Yves for pointing out the maritime tag.

I may be missing something, Christoph, but doesn't a combined search for 
admin_level=X & maritime=yes remove any misuse of the maritime tag & 
produced the required solution?


DaveF

On 10/03/2018 19:16, Christoph Hormann wrote:

On Saturday 10 March 2018, Dave F wrote:

If Matthijs wishes to distinguish between boundaries at sea (a good
idea, I believe) then a *unique* tag should be added to those ways.

Note independent of the subject of this thread the tag maritime=yes -
which is what is proposed to be used for determining the border style
in the map - is somewhat ill defined.  There are a number of different
types of borders that are widely tagged with this (though not all of
them universally):

* the outer limits of the territorial waters of a country towards the
high seas (usually 12 miles from the baseline).  This is the original
declared purpose of maritime=yes and these are very often tagged this
way if other boundary tags exist on the way (boundary=administrative +
admin_level=2) - see also wambacher's illustrations - boundaries
missing there have usually none of the tags in question.
* admin_level 2 boundaries between two countries over maritime water.
These are usually also tagged maritime=yes.
* the outer limits of higher level administrative units towards the
ocean - which can be either at a certain distance from the baseline
(like in the US) or at the coastline (like in Danmark or France -
although technically this is typically the low tide line while the
coastline is at the high water line).  These are not universally tagged
with maritime=yes (not commonly for example in Italy, Spain, Mexico and
Iran).
* The US - Canada border in the Great Lakes (which is a clear misuse of
the tag).




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

Re: [Tagging] Tagging request: missing admin_level tags

[Christoph Hormann]

On Saturday 10 March 2018, Dave F wrote:
> If Matthijs wishes to distinguish between boundaries at sea (a good
> idea, I believe) then a *unique* tag should be added to those ways.

Note independent of the subject of this thread the tag maritime=yes - 
which is what is proposed to be used for determining the border style 
in the map - is somewhat ill defined.  There are a number of different 
types of borders that are widely tagged with this (though not all of 
them universally):

* the outer limits of the territorial waters of a country towards the 
high seas (usually 12 miles from the baseline).  This is the original 
declared purpose of maritime=yes and these are very often tagged this 
way if other boundary tags exist on the way (boundary=administrative + 
admin_level=2) - see also wambacher's illustrations - boundaries 
missing there have usually none of the tags in question.
* admin_level 2 boundaries between two countries over maritime water.  
These are usually also tagged maritime=yes.
* the outer limits of higher level administrative units towards the 
ocean - which can be either at a certain distance from the baseline 
(like in the US) or at the coastline (like in Danmark or France - 
although technically this is typically the low tide line while the 
coastline is at the high water line).  These are not universally tagged 
with maritime=yes (not commonly for example in Italy, Spain, Mexico and 
Iran).
* The US - Canada border in the Great Lakes (which is a clear misuse of 
the tag).

-- 
Christoph Hormann
http://www.imagico.de/

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

Re: [Tagging] Tagging request: missing admin_level tags

[Walter Nordmann]

Hi dave,

Am 10.03.2018 um 18:04 schrieb Dave F:

How about boundary:administration=maritime (or something similar)?

about 97% of all 12010 maritim admin boundaries (boundaries not on any 
land area) have been tagged with maritime=yes.


https://wambachers-osm.website/images/osm/snaps_2018/maritime1.png
https://wambachers-osm.website/images/osm/snaps_2018/maritime2.png
https://wambachers-osm.website/images/osm/snaps_2018/maritime3.png
https://wambachers-osm.website/images/osm/snaps_2018/maritime4.png

Some are missing and some should be changed. or we should filter on 
additional tags.


regards
walter aka wambacher

___
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: missing admin_level tags

[Dave F]

If Matthijs wishes to distinguish between boundaries at sea (a good 
idea, I believe) then a *unique* tag should be added to those ways. 
Duplicating data is not the way to indicate differences.


How about boundary:administration=maritime (or something similar)?

I've never understood why the highest admin_level value is required to 
be placed on the way at all, when it's clearly calculable from the 
relations. Data shouldn't be duplicated purely for the convenience of 
renderers (or is it just one renderer?). I would support removing them.


Having read the links provided by Christoph, I find it very 
disappointing there are some who still believe the time spent by mappers 
adding data is somehow subservient to the time of those coding. It's 
another case of the tail waging the dog.


DaveF.


On 10/03/2018 08:14, Colin Smale wrote:


Matthijs,

This goes against the principle of tagging the relation, not the 
members. An admin area is syntactically analogous to a multipolygon 
and it would be a shame to introduce yet another polygon tagging paradigm.


What are you thinking for other types of 
boundaries? boundary=political, boundary=national_park come to mind. 
Will they be treated differently to boundary=administrative?


What do you intend exactly when you say "maritime boundaries"? That 
part of a (national) boundary which crosses water? Or some other 
definition?


Colin

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=51.92203=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


___
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é.

Re: [Tagging] Different postal codes in each side of the street

[Fernando Trebien]

Thank you everyone for your attentive answers.

From your information and some detailed testing, I think that for
Brazil it is best to use boundary=postal_code for the vast majority of
municipalities with small population, with addr:postcode for a few
elements with exceptional postal codes. It also seems that in the long
term this would be the best solution for larger cities as well [1],
though in the short term we may keep using addr:postcode for most
addresses, or postal_code whenever both sides of a street have the
same postal code. We surely should not use tiger:* tags, as the scope
of those is by definition limited to the US.

Note: in my tests, Nominatim seemed to have some issues computing its
postcode field when tiger:zip_left and tiger:zip_right are different.

[1] (pt) https://forum.openstreetmap.org/viewtopic.php?pid=688791

-- 
Fernando Trebien
+55 (51) 9962-5409

"Nullius in verba."

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

Re: [Tagging] Tagging request: missing admin_level tags

[Colin Smale]

On 2018-03-10 11:56, osm.tagg...@thorsten.engler.id.au wrote:

> I agree that the priorities need to be codified (for the standard style), but 
> this remains unchanged, no matter if the boundaries are rendered by polygon 
> or by way.

Sorry, you are right, I should have made that clear; I was intending to
refer to the standard style as shown on openstreetmap.org. 

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

Re: [Tagging] Tagging request: missing admin_level tags

[osm.tagging]

I agree that the priorities need to be codified (for the standard style), but 
this remains unchanged, no matter if the boundaries are rendered by polygon or 
by way.

 

Also, this is not something that should be decided or controlled by the 
mapper/data. The map database just collects all the available information. What 
of that data to use, and how to prioritize different data is up to every 
individual consumer, with osm-carto just being one of many.

 

From: Colin Smale  
Sent: Saturday, 10 March 2018 20:46
To: tagging@openstreetmap.org
Subject: Re: [Tagging] Tagging request: missing admin_level tags

 

On 2018-03-10 11:31, osm.tagg...@thorsten.engler.id.au 
  wrote:

There is nothing about the data that's desired on the ways that requires any 
sort of human decision making, it can all be automatically derived from 
information that's already available.

 

One thing that should maybe be codified, is where multiple types of boundary 
coincide. For boundary=administrative it is pretty clear that the lowest value 
of admin_level takes precedence for the rendering, but what about if it is 
co-linear with a political boundary for example? I would expect the rendering 
for the admin boundary to take precedence here, but does everyone agree with 
that? What about the boundary of a police area combined with an admin boundary?

 

I am raising it here because it is subjective, i.e. subject to human decision 
making, in the absence of any consensus about the relative rendering priorities 
of these boundary types.

 

Colin

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

Re: [Tagging] Tagging request: missing admin_level tags

[Colin Smale]

On 2018-03-10 11:31, osm.tagg...@thorsten.engler.id.au wrote:

>> There is nothing about the data that's desired on the ways that requires any 
>> sort of human decision making, it can all be automatically derived from 
>> information that's already available.

One thing that should maybe be codified, is where multiple types of
boundary coincide. For boundary=administrative it is pretty clear that
the lowest value of admin_level takes precedence for the rendering, but
what about if it is co-linear with a political boundary for example? I
would expect the rendering for the admin boundary to take precedence
here, but does everyone agree with that? What about the boundary of a
police area combined with an admin boundary? 

I am raising it here because it is subjective, i.e. subject to human
decision making, in the absence of any consensus about the relative
rendering priorities of these boundary types. 

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

Re: [Tagging] Tagging request: missing admin_level tags

[osm.tagging]

Also, I don't understand why the information would need to be manually tagged 
on the ways at all. Duplicating derivable information in a database seems like 
a very stupid move to me. All the required information is there already.

If some part of the process wants to go on information attached to the ways, 
but the information is stored on the multipolys that reference these ways, then 
some earlier process should automatically copy that information from the 
multipolys into the (temporary, "in-memory") representation of the ways. 

This sounds like a purely technical issue to me that should not require any 
changes (especially ones that go against all established practices) to the 
underlying database.

There is nothing about the data that's desired on the ways that requires any 
sort of human decision making, it can all be automatically derived from 
information that's already available.

> -Original Message-
> From: Tom Pfeifer 
> Sent: Saturday, 10 March 2018 20:17
> To: tagging@openstreetmap.org
> Subject: Re: [Tagging] Tagging request: missing admin_level tags
> 
> On 10.03.2018 09:36, Simon Poole wrote:
> > I would have to second this observation, this would seem to go
> exactly
> > against what we've tried to fix with multi-polygons (not to
> mention a
> > future area object type). Not to mention that a single way can be
> a
> > member of multiple different borders at different admin levels, so
> this would seem to be a non-starter in any case.
> 
> In addition, the border ways can be other objects. Rivers are quite
> typical, which are easily included in a border relation. Tagging all
> border properties on the waterway leads to chaos.
> 
> Besides the minor and not yet explained "maritime boundaries" case -
> what are the other advantages of the proposed change?
> 
> tom
> 
> >> 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.
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



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

Re: [Tagging] Tagging request: missing admin_level tags

[Tom Pfeifer]

On 10.03.2018 09:36, Simon Poole wrote:
I would have to second this observation, this would seem to go exactly against what we've tried to 
fix with multi-polygons (not to mention a future area object type). Not to mention that a single way 
can be a member of multiple different borders at different admin levels, so this would seem to be a 
non-starter in any case.


In addition, the border ways can be other objects. Rivers are quite typical, which are easily 
included in a border relation. Tagging all border properties on the waterway leads to chaos.


Besides the minor and not yet explained "maritime boundaries" case - what are the other advantages 
of the proposed change?


tom


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.


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

Re: [Tagging] Tagging request: missing admin_level tags

[osm.tagging]

This sounds like an absolutely horrible idea to me that totally goes against 
the tagging paradigms that have been in effect so far.

Also, as Simon pointed out, a single way can belong to multiple multipolys at 
the same time, each with different admin levels, or even ways that in itself 
represent some other feature (e.g if the admin boundary is following along some 
natural feature like a waterway).

For whatever my vote is worth, I'm strongly opposed to this.

> -Original Message-
> From: Matthijs Melissen 
> Sent: Saturday, 10 March 2018 10:51
> To: Tag discussion, strategy and related tools
> 
> Subject: [Tagging] Tagging request: missing admin_level tags
> 
> 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=51.92203=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

Re: [Tagging] Tagging request: missing admin_level tags

[Walter Nordmann]

Hi Jo,

this IS a step backwards! please wait for the results of this discussion 
before changing anything.


regards

walter aka wambacher


Am 10.03.2018 um 10:30 schrieb Jo:
I added many borders in Uganda a few years ago, they are gray in your 
rendering. Should I go and put admin_level tags on them now? For the 
highest or the lowest admin_level they are part of?



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

Re: [Tagging] Tagging request: missing admin_level tags

[Jo]

I added many borders in Uganda a few years ago, they are gray in your
rendering. Should I go and put admin_level tags on them now? For the
highest or the lowest admin_level they are part of?

Or a semicolon separated list...?

Seems like a step backward to me, but I guess, whatever works.

Polyglot

2018-03-10 10:15 GMT+01:00 Christoph Hormann :

> On Saturday 10 March 2018, Matthijs Melissen wrote:
> > [...] This has a number of advantages -
> > for example, it will make it possible to style maritime boundaries
> > differently.
>
> I have already strongly voiced by opinion on this in the style
> development discussion:
>
> https://github.com/gravitystorm/openstreetmap-
> carto/pull/2950#issuecomment-345839634
> https://github.com/gravitystorm/openstreetmap-
> carto/pull/3074#issuecomment-368227660
> https://github.com/gravitystorm/openstreetmap-
> carto/pull/3102#issuecomment-370394640
>
> But i want to add here that the statement cited above is simply wrong.
> There are lots of ways you can style maritime boundaries differently -
> some of them are difficult using the tool chain currently used by
> OSM-Carto, others come with design restrictions - just like the status
> quo in the style or the method you are planning to use.  But the idea
> that this approach is without good alternatives is a misapprehension of
> the situation.
>
> --
> Christoph Hormann
> http://www.imagico.de/
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging request: missing admin_level tags

[Christoph Hormann]

On Saturday 10 March 2018, Matthijs Melissen wrote:
> [...] This has a number of advantages -
> for example, it will make it possible to style maritime boundaries
> differently.

I have already strongly voiced by opinion on this in the style 
development discussion:

https://github.com/gravitystorm/openstreetmap-carto/pull/2950#issuecomment-345839634
https://github.com/gravitystorm/openstreetmap-carto/pull/3074#issuecomment-368227660
https://github.com/gravitystorm/openstreetmap-carto/pull/3102#issuecomment-370394640

But i want to add here that the statement cited above is simply wrong.  
There are lots of ways you can style maritime boundaries differently - 
some of them are difficult using the tool chain currently used by 
OSM-Carto, others come with design restrictions - just like the status 
quo in the style or the method you are planning to use.  But the idea 
that this approach is without good alternatives is a misapprehension of 
the situation.

-- 
Christoph Hormann
http://www.imagico.de/

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

Re: [Tagging] Tagging request: missing admin_level tags

[Simon Poole]

I would have to second this observation, this would seem to go exactly
against what we've tried to fix with multi-polygons (not to mention a
future area object type). Not to mention that a single way can be a
member of multiple different borders at different admin levels, so this
would seem to be a non-starter in any case.

Simon


Am 10.03.2018 um 09:14 schrieb Colin Smale:
>
> Matthijs,
>
> This goes against the principle of tagging the relation, not the
> members. An admin area is syntactically analogous to a multipolygon
> and it would be a shame to introduce yet another polygon tagging paradigm.
>
> What are you thinking for other types of
> boundaries? boundary=political, boundary=national_park come to mind.
> Will they be treated differently to boundary=administrative?
>
>  
>
> What do you intend exactly when you say "maritime boundaries"? That
> part of a (national) boundary which crosses water? Or some other
> definition?
>
> Colin
>
> 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=51.92203=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



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging request: missing admin_level tags

[Colin Smale]

Matthijs, 

This goes against the principle of tagging the relation, not the
members. An admin area is syntactically analogous to a multipolygon and
it would be a shame to introduce yet another polygon tagging paradigm. 

What are you thinking for other types of boundaries? boundary=political,
boundary=national_park come to mind. Will they be treated differently to
boundary=administrative?

What do you intend exactly when you say "maritime boundaries"? That part
of a (national) boundary which crosses water? Or some other definition? 

Colin 

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=51.92203=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