Re: [Tagging] Tagging request: missing admin_level tags

[Matthijs Melissen]

On 19 March 2018 at 00:27, Dave F  wrote:
> It's been agreed they are redundant.

Perhaps a bit too early for that statement, please note that the
discussion on the osm-carto side is still ongoing:
https://github.com/gravitystorm/openstreetmap-carto/pull/3102#issuecomment-374062776

> I'd recommend
>
> adding maritime=yes to all required ways that don't have them.
> adding boundary=administrative relations to ways the require them
> removing admin_level & boundary=administrative from ways which have them in
> relations

Just to be clear, you propose removing boundary=administrative from
maritime borders, but leaving the maritime=yes tag? So this will
result in many ways with the only tag maritime=yes?

-- Matthijs

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

Re: [Tagging] Tagging request: missing admin_level tags

[Andrew Hain]

I agree entirely with Dave on this. Consider this a request to consider 
systematically removing the admin_level tag from ways or making it a 
discardable tag only for ways.

--
Andrew


From: Dave F <davefoxfa...@btinternet.com>
Sent: 11 March 2018 23:49:45
To: tagging@openstreetmap.org
Subject: Re: [Tagging] Tagging request: missing admin_level tags

On 11/03/2018 09:51, Christoph Hormann wrote:
>
> * tagging the ways in addition to the relation is ok but not required.

I agree with all your points except this. I think duplication is prone
to error & should be discouraged.

DaveF.

___
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

[Yuri Astrakhan]

Paul Norman wrote OSMBorder  about a
year ago to help with the border drawing. It generates a pgsql table with
line strings (not polygons), each way having the lowest value for the
"admin level". So if a way belongs to both a country and a city border, the
table will have just one way instance, with the lowest admin_level of the
two usages. Also, the polygon is not required to be closed, so broken
relations continue to be drawn properly for most of the map.

P.S. I also think that duplicating information like admin_level inside a
way and in a relation is a bad practice. I think it came about due to the
limitations in the viewing software, and should be solved with proper tools
(web site, josm, iD, etc), rather than having dups that often go out of
sync.

On Mon, Mar 12, 2018 at 9:52 AM, Dave F  wrote:

> Yes, but again, irrelevant to this thread.
>
>
> On 12/03/2018 13:44, Jo wrote:
>
> Except of course, when the boundary is disputed, then there might be
> overlap and possibly even holes of no man's land?
>
> Polyglot
>
> 2018-03-12 13:41 GMT+01:00 Dave F :
>
>> OK, I understand what you're trying to highlight, but don't see it as
>> relevant to this thread.
>> But anyway, the "boundary between two countries" can be distinguished as
>> they'll have two relations with boundary data whereas "the high seas"
>> boundary will only have one.
>>
>> DaveF.
>>
>> On 12/03/2018 00:17, Christoph Hormann wrote:
>>
>>> On Monday 12 March 2018, Dave F wrote:
>>>
 and it would not distinguish between the outer boundaries (towards
> the high seas)
> and the boundaries between two countries.
>
 Unsure what you mean. Could you elaborate, Example?

 Sure:
>>>
>>> https://www.openstreetmap.org/way/96104334
>>>
>>> is an outer maritime boundary at 12 mile distance from the baseline
>>> separating the territorial waters from the high seas.
>>>
>>> OTOH
>>>
>>> https://www.openstreetmap.org/way/54749533
>>>
>>> is a maritime boundary between two countries.
>>>
>>> You might say this difference is not of practical importance for data
>>> users but there are for example many maps which generally do not show
>>> the first type of boundary but which do show (at least partly) the
>>> second type of boundary.  Like this:
>>>
>>> http://legacy.lib.utexas.edu/maps/cia16/denmark_sm_2016.gif
>>>
>>> You can of course determine this difference from the spatial
>>> relationship of the boundary relations.
>>>
>>>
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>
>
>
> ___
> Tagging mailing 
> listTagging@openstreetmap.orghttps://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: missing admin_level tags

[Dave F]

Yes, but again, irrelevant to this thread.

On 12/03/2018 13:44, Jo wrote:
Except of course, when the boundary is disputed, then there might be 
overlap and possibly even holes of no man's land?


Polyglot

2018-03-12 13:41 GMT+01:00 Dave F >:


OK, I understand what you're trying to highlight, but don't see it
as relevant to this thread.
But anyway, the "boundary between two countries" can be
distinguished as they'll have two relations with boundary data
whereas "the high seas" boundary will only have one.

DaveF.

On 12/03/2018 00:17, Christoph Hormann wrote:

On Monday 12 March 2018, Dave F wrote:

and it would not distinguish between the outer
boundaries (towards
the high seas)
and the boundaries between two countries.

Unsure what you mean. Could you elaborate, Example?

Sure:

https://www.openstreetmap.org/way/96104334


is an outer maritime boundary at 12 mile distance from the
baseline
separating the territorial waters from the high seas.

OTOH

https://www.openstreetmap.org/way/54749533


is a maritime boundary between two countries.

You might say this difference is not of practical importance
for data
users but there are for example many maps which generally do
not show
the first type of boundary but which do show (at least partly) the
second type of boundary.  Like this:

http://legacy.lib.utexas.edu/maps/cia16/denmark_sm_2016.gif


You can of course determine this difference from the spatial
relationship of the boundary relations.



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

[Jo]

Except of course, when the boundary is disputed, then there might be
overlap and possibly even holes of no man's land?

Polyglot

2018-03-12 13:41 GMT+01:00 Dave F :

> OK, I understand what you're trying to highlight, but don't see it as
> relevant to this thread.
> But anyway, the "boundary between two countries" can be distinguished as
> they'll have two relations with boundary data whereas "the high seas"
> boundary will only have one.
>
> DaveF.
>
> On 12/03/2018 00:17, Christoph Hormann wrote:
>
>> On Monday 12 March 2018, Dave F wrote:
>>
>>> and it would not distinguish between the outer boundaries (towards
 the high seas)
 and the boundaries between two countries.

>>> Unsure what you mean. Could you elaborate, Example?
>>>
>>> Sure:
>>
>> https://www.openstreetmap.org/way/96104334
>>
>> is an outer maritime boundary at 12 mile distance from the baseline
>> separating the territorial waters from the high seas.
>>
>> OTOH
>>
>> https://www.openstreetmap.org/way/54749533
>>
>> is a maritime boundary between two countries.
>>
>> You might say this difference is not of practical importance for data
>> users but there are for example many maps which generally do not show
>> the first type of boundary but which do show (at least partly) the
>> second type of boundary.  Like this:
>>
>> http://legacy.lib.utexas.edu/maps/cia16/denmark_sm_2016.gif
>>
>> You can of course determine this difference from the spatial
>> relationship of the boundary relations.
>>
>>
>
> ___
> 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

[Dave F]

OK, I understand what you're trying to highlight, but don't see it as 
relevant to this thread.
But anyway, the "boundary between two countries" can be distinguished as 
they'll have two relations with boundary data whereas "the high seas" 
boundary will only have one.


DaveF.

On 12/03/2018 00:17, Christoph Hormann wrote:

On Monday 12 March 2018, Dave F wrote:

and it would not distinguish between the outer boundaries (towards
the high seas)
and the boundaries between two countries.

Unsure what you mean. Could you elaborate, Example?


Sure:

https://www.openstreetmap.org/way/96104334

is an outer maritime boundary at 12 mile distance from the baseline
separating the territorial waters from the high seas.

OTOH

https://www.openstreetmap.org/way/54749533

is a maritime boundary between two countries.

You might say this difference is not of practical importance for data
users but there are for example many maps which generally do not show
the first type of boundary but which do show (at least partly) the
second type of boundary.  Like this:

http://legacy.lib.utexas.edu/maps/cia16/denmark_sm_2016.gif

You can of course determine this difference from the spatial
relationship of the boundary relations.




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

Re: [Tagging] Tagging request: missing admin_level tags

[osm.tagging]

> -Original Message-
> From: Kevin Kenny <kevin.b.kenny+...@gmail.com>
> Sent: Monday, 12 March 2018 11:15
> To: Tag discussion, strategy and related tools
> <tagging@openstreetmap.org>
> Subject: Re: [Tagging] Tagging request: missing admin_level tags

> I'm glad we're in agreement here. This was my key point: the fact
> that the existing rendering technology makes implementing 'render at
> most one boundary on any given way' insanely difficult when the
> boundaries are associated with relations that the way is a member of.
> With osm2pgsql, I'm not sure that's even possible without digging
> through the slim tables, and I've certainly never managed to
> implement a rendering that gets it right.
> 
> If we can fix the main technical issue, the tagging problem becomes
> much less significant. I was hoping this discussion might bring out
> of the woodwork a programmer who's clever enough to solve it cleanly.

I believe that this open issue would probably get you most of the way towards a 
viable technical solution:

https://github.com/openstreetmap/osm2pgsql/issues/230



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

Re: [Tagging] Tagging request: missing admin_level tags

[Daniel Koć]

W dniu 11.03.2018 o 23:50, Kevin Kenny pisze:


A fair number of users here - including me - render our own maps, and
are giving feedback based on our own experience with trying to render
them. I know that in discussions on 'tagging' I try to hide the fact
that wanting to render something is driving my opinion, because of the
widespread misinterpretation of the 'tagging for the renderer' slogan.


Thanks a lot for your comments. That's what I expected - I believe some 
problems are reported from the experience and it's good to know what 
kind of circumstances makes the problem visible.


I encourage people to be more open about the problems they have - 
including how it affects routing, rendering (probably two most common 
scenarios) or any other. Decoupling data from the usage makes it easier 
to have wider ecosystem, but data don't live on their own. The model 
they create should be accurate (that's the part we usually discuss a 
lot), but also practical to use (I won't cite jokes, read some examples 
about it for example here: 
https://nargaque.com/2014/03/02/mathematicians-answer/ ).



As it happens, osm-carto is reporting an issue that I've encountered
independently.


Maybe we miss special place to discuss map rendering problems with OSM 
data? I can create one on the OSM forum server.


It strikes me sometimes, that we in the osm-carto tend to discuss 
general things about rendering in whatever current ticket they affect, 
just because we have no better space for this. If we could share 
experiences from different renderers, it would be even more useful.


--
"My method is uncertain/ It's a mess but it's working" [F. Apple]


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

Re: [Tagging] Tagging request: missing admin_level tags

[Kevin Kenny]

On Sun, Mar 11, 2018 at 7:24 PM, Warin <61sundow...@gmail.com> wrote:
[in reply to my message:]
>> I'm sure that this difficulty is part of what motivates the OSM-Carto
>> group to be requesting that all ways that participate in admin
>> boundaries be tagged with the "most important" boundary in which they
>> appear. This tagging gives an easy route to displaying the border
>> unambiguously - drive the renderer from the ways and not the
>> relations.
>
> No. If I were to make a decision on which is 'more important' I will make it
> based on my interpretation. That may not match yours.

Right! We're in 'violent agreement' here.  I was describing the likely
motivation for wanting the tagging on the enclosing ways.
>
> The renders should make the choice based on what they want to render i.e.
> which one is 'more important' for that map.

Right again. Admin boundaries, however, are somewhat
heterogeneous. Many renderers want to show them - political
boundaries are important in a lot of contexts - and I don't
mind having an 'admin_level' hierarchy. That said, if a renderer
wants to impose a different idea of the world, it should be free to.

>> I think this is a particular case where the political problem needs a
>> technical solution. I have not yet been clever enough to invent a
>> method in the PostGIS-Mapnik pipeline to identify ways that
>> participate in administrative boundary relations, select the "most
>> important" boundary and display each way only once, no matter how many
>> relations use it.  This is, of course, what is needed for a good many
>> rendering problems, where the definition of "most important" may be
>> specific to a particular renderer. If we had skeleton code showing how
>> such a thing would operate, I'm sure that the OSM-Carto team could
>> adapt to it, (and so could I, on the maps that I render!).
>
>
> Yes.

I'm glad we're in agreement here. This was my key point: the fact
that the existing rendering technology makes implementing
'render at most one boundary on any given way' insanely
difficult when the boundaries are associated with relations
that the way is a member of. With osm2pgsql, I'm not sure
that's even possible without digging through the slim tables,
and I've certainly never managed to implement a rendering
that gets it right.

If we can fix the main technical issue, the tagging problem
becomes much less significant. I was hoping this discussion
might bring out of the woodwork a programmer who's clever
enough to solve it cleanly.

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

Re: [Tagging] Tagging request: missing admin_level tags

[Christoph Hormann]

On Monday 12 March 2018, Dave F wrote:
>
> > and it would not distinguish between the outer boundaries (towards
> > the high seas)
> > and the boundaries between two countries.
>
> Unsure what you mean. Could you elaborate, Example?
>

Sure:

https://www.openstreetmap.org/way/96104334

is an outer maritime boundary at 12 mile distance from the baseline 
separating the territorial waters from the high seas.

OTOH

https://www.openstreetmap.org/way/54749533

is a maritime boundary between two countries.

You might say this difference is not of practical importance for data 
users but there are for example many maps which generally do not show 
the first type of boundary but which do show (at least partly) the 
second type of boundary.  Like this:

http://legacy.lib.utexas.edu/maps/cia16/denmark_sm_2016.gif

You can of course determine this difference from the spatial 
relationship of the boundary relations.

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

[Dave F]

On 11/03/2018 09:51, Christoph Hormann wrote:


* tagging the ways in addition to the relation is ok but not required.


I agree with all your points except this. I think duplication is prone 
to error & should be discouraged.


DaveF.

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

Re: [Tagging] Tagging request: missing admin_level tags

[Dave F]

On 10/03/2018 22:17, Christoph Hormann wrote:
But as pointed out this will not be complete (though more complete 
than for land boundaries) 


I would much prefer to complete the addition of the unique tag 
'maritime' than the duplicating 'admin_level'


and it would not distinguish between the outer boundaries (towards the 
high seas)

and the boundaries between two countries.


Unsure what you mean. Could you elaborate, Example?


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.




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

Re: [Tagging] Tagging request: missing admin_level tags

[Warin]

On 3/12/2018 9:50 AM, Kevin Kenny wrote:

On Sun, Mar 11, 2018 at 2:18 PM, Daniel Koć  wrote:

3. The OSM community (as a whole) is blinded by the sound of term
"tagging for rendering". I think it gave rendering pretty bad publicity,
while in fact this is a tagging (!) problem and is about making up false
data for some purpose. The most common case seems to be making the data
to look on the particular map as the mappers like it to have, but still
it doesn't make rendering something bad.

4. While osm-carto is just one renderer of OSM data, it is the one I'm
aware of which gives any feedback about rendering problems. More than
this: IIRC, this is also the only one consumer project which gives the
feedback to data community. I treat it as a valuable source of
information what could be missing or broken with our data models. After
all rendering maps is a pretty common way of consuming GIS data.

A fair number of users here - including me - render our own maps, and
are giving feedback based on our own experience with trying to render
them. I know that in discussions on 'tagging' I try to hide the fact
that wanting to render something is driving my opinion, because of the
widespread misinterpretation of the 'tagging for the renderer' slogan.

The meaning of the slogan is that you shouldn't tag an object as what
it is not, simply to make it render prettily on the default
renderer. On the other hand, discussing how to distinguish one sort of
object from another, when the motivation is to be able to render them
differently on a custom map, is a tagging question - and I've had such
questions dismissed as 'tagging for the renderer.' It isn't 'tagging
for the renderer' when it's an assertion that "two objects tagged
exactly alike cannot be distinguished by any conceivable renderer!"

As it happens, osm-carto is reporting an issue that I've encountered
independently. Using the currently favoured model where administrative
regions are multipolygons, tagged "boundary=administrative
admin_level=N", it is easy to extract the edges and draw along
them. However, it is much less straightforward to recognize that a way
is common to multiple administrative regions, either because the
regions are contiguous, or because regions at different admin_levels
are sharing the same boundary. In a typical renderer, this difficulty
leads to overdrawing the boundary.  Particularly for textured
boundaries (various sorts of dash patterns, for instance), overdrawing
leads to illegible maps.

I'm sure that this difficulty is part of what motivates the OSM-Carto
group to be requesting that all ways that participate in admin
boundaries be tagged with the "most important" boundary in which they
appear. This tagging gives an easy route to displaying the border
unambiguously - drive the renderer from the ways and not the
relations.


No. If I were to make a decision on which is 'more important' I will make it 
based on my interpretation. That may not match yours.

The renders should make the choice based on what they want to render i.e. which 
one is 'more important' for that map.




I think this is a particular case where the political problem needs a
technical solution. I have not yet been clever enough to invent a
method in the PostGIS-Mapnik pipeline to identify ways that
participate in administrative boundary relations, select the "most
important" boundary and display each way only once, no matter how many
relations use it.  This is, of course, what is needed for a good many
rendering problems, where the definition of "most important" may be
specific to a particular renderer. If we had skeleton code showing how
such a thing would operate, I'm sure that the OSM-Carto team could
adapt to it, (and so could I, on the maps that I render!).


Yes.



I think the problem of making the actual rendering connection is
technically deep enough to cause people to request infelicitous
tagging to work around it.  If the underlying problem can be solved,
then the tagging problem goes away.



As I said .. making the choice at the tagging stage means the resulting maps 
may all be just the same...

and that is not a good thing! This choice should be made by the map maker, not 
the data recorder.

As the admin boundaries are numbered in the order of importance to 
administrators ...
a choice can be made to use that as the rendering importance.
That is one choice that can be made now with no extra tags.
This still leaves others to chose a different order of importance without being 
distracted by some tag or other.


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

Re: [Tagging] Tagging request: missing admin_level tags

[Kevin Kenny]

On Sun, Mar 11, 2018 at 2:18 PM, Daniel Koć  wrote:
> 3. The OSM community (as a whole) is blinded by the sound of term
> "tagging for rendering". I think it gave rendering pretty bad publicity,
> while in fact this is a tagging (!) problem and is about making up false
> data for some purpose. The most common case seems to be making the data
> to look on the particular map as the mappers like it to have, but still
> it doesn't make rendering something bad.
>
> 4. While osm-carto is just one renderer of OSM data, it is the one I'm
> aware of which gives any feedback about rendering problems. More than
> this: IIRC, this is also the only one consumer project which gives the
> feedback to data community. I treat it as a valuable source of
> information what could be missing or broken with our data models. After
> all rendering maps is a pretty common way of consuming GIS data.

A fair number of users here - including me - render our own maps, and
are giving feedback based on our own experience with trying to render
them. I know that in discussions on 'tagging' I try to hide the fact
that wanting to render something is driving my opinion, because of the
widespread misinterpretation of the 'tagging for the renderer' slogan.

The meaning of the slogan is that you shouldn't tag an object as what
it is not, simply to make it render prettily on the default
renderer. On the other hand, discussing how to distinguish one sort of
object from another, when the motivation is to be able to render them
differently on a custom map, is a tagging question - and I've had such
questions dismissed as 'tagging for the renderer.' It isn't 'tagging
for the renderer' when it's an assertion that "two objects tagged
exactly alike cannot be distinguished by any conceivable renderer!"

As it happens, osm-carto is reporting an issue that I've encountered
independently. Using the currently favoured model where administrative
regions are multipolygons, tagged "boundary=administrative
admin_level=N", it is easy to extract the edges and draw along
them. However, it is much less straightforward to recognize that a way
is common to multiple administrative regions, either because the
regions are contiguous, or because regions at different admin_levels
are sharing the same boundary. In a typical renderer, this difficulty
leads to overdrawing the boundary.  Particularly for textured
boundaries (various sorts of dash patterns, for instance), overdrawing
leads to illegible maps.

I'm sure that this difficulty is part of what motivates the OSM-Carto
group to be requesting that all ways that participate in admin
boundaries be tagged with the "most important" boundary in which they
appear. This tagging gives an easy route to displaying the border
unambiguously - drive the renderer from the ways and not the
relations.

Nevertheless, easy is not always right. This tagging of the ways
violates the principle of "Don't Repeat Yourself."  Any time that you
have the same data in two places in a data model, you open the
opportunity for those two places to get out of sync.

I think this is a particular case where the political problem needs a
technical solution. I have not yet been clever enough to invent a
method in the PostGIS-Mapnik pipeline to identify ways that
participate in administrative boundary relations, select the "most
important" boundary and display each way only once, no matter how many
relations use it.  This is, of course, what is needed for a good many
rendering problems, where the definition of "most important" may be
specific to a particular renderer. If we had skeleton code showing how
such a thing would operate, I'm sure that the OSM-Carto team could
adapt to it, (and so could I, on the maps that I render!).

I think the problem of making the actual rendering connection is
technically deep enough to cause people to request infelicitous
tagging to work around it.  If the underlying problem can be solved,
then the tagging problem goes away.

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

Re: [Tagging] Tagging request: missing admin_level tags

[Martin Koppenhoefer]

sent from a phone

> On 10. Mar 2018, at 11:16, Tom Pfeifer  wrote:
> 
> 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.


+1, there are really lots of reasons not to go back to rendering admin 
boundaries from ways.

IMHO the main style should try to render what people are mapping, not try to 
make them change their mapping for the current implementation of the rendering 
rules (“if you don’t act now all your nice borders will go away soon” ;-) ), 
particularly if the former is the result of long term evolution.


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

Re: [Tagging] Tagging request: missing admin_level tags

[Daniel Koć]

Thanks for writing this summary! It's short, but made me realize a few
fundamental points:

W dniu 11.03.2018 o 01:31, Matthijs Melissen pisze:

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

1. I think it's also important from the consistency point of view. If we
really don't want to add another 10% for completeness, maybe we should
remove the current 90% to avoid duplication?

2. Here I see also a general problem of "low zoom levels" (read - global
objects):

When we have thousands of roads, we might have specific regional
definitions and conventions - it's not comfortable and violates
consistency, but allows us to cover world diversity. It would be hard to
just collect them all and find one template.

But when talking about country (maritime) borders, we have only about a
dozen of them and it's perfectly achievable to coin the global rules.
It's even favorable - if we tag a hundred of roads bad, it's not that
visible, but with just one exception of what maritime border means for
one person, we have a flawed data set and silly visualization of the world:

https://help.openstreetmap.org/questions/57394/maritime-border-of-peru
https://www.openstreetmap.org/relation/288247

I understand that growing from very local London-based project results
in a certain way of thinking about data, which mostly works good, but we
have reached the point where some global issues have appeared and we
should address them accordingly.

> I would also like to point out that other data consumers do rely on
> the presence of admin_level on boundary ways too.

3. The OSM community (as a whole) is blinded by the sound of term
"tagging for rendering". I think it gave rendering pretty bad publicity,
while in fact this is a tagging (!) problem and is about making up false
data for some purpose. The most common case seems to be making the data
to look on the particular map as the mappers like it to have, but still
it doesn't make rendering something bad.

4. While osm-carto is just one renderer of OSM data, it is the one I'm
aware of which gives any feedback about rendering problems. More than
this: IIRC, this is also the only one consumer project which gives the
feedback to data community. I treat it as a valuable source of
information what could be missing or broken with our data models. After
all rendering maps is a pretty common way of consuming GIS data.

Of course, as a member of osm-carto team and reporter of such problems I
may be not objective, but this is what I believe and I don't feel more
like a "map designer" than OSM community member.

--
"My method is uncertain/ It's a mess but it's working" [F. Apple]


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

Re: [Tagging] Tagging request: missing admin_level tags

[Frederik Ramm]

Hi,

On 10.03.2018 01:51, Matthijs Melissen wrote:
> I would therefore suggest
> to make sure admin_level tags are present on all
> boundary=administrative ways.

I can see how this makes rendering easier, but OSM isn't mainly a
database for rendering. I don't see why a river that serves as an admin
boundary should even have a boundary=administrative tag; including it in
the relevant relation should be enough.

Also when the admin_level of an area changes (due to either a political
change or a change of mind in the OSM community about what should be
which admin level in the particular country), I don't want to force
mappers to change the tagging of all affected ways.

On the whole, the openstreetmap-carto team usually has a positive
influence on tagging in OSM and provides the occasional nudge for
mappers to standardise something. In this particular case, I would say
this is an undue request, and the change in tagging would be for the worse.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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

Re: [Tagging] Tagging request: missing admin_level tags

[Christoph Hormann]

On Sunday 11 March 2018, Matthijs Melissen wrote:
>
> 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.

As several people have pointed out admin_level tagging on boundary ways 
is essentially a relict from past times were boundary relations were 
not yet established.

OSM-Carto continued rendering boundaries both from relations *and* ways 
until November 2015 
(https://github.com/gravitystorm/openstreetmap-carto/pull/1938 and 
https://github.com/gravitystorm/openstreetmap-carto/pull/1989).  Since 
then it uses relations only (except for the closed way case - see 
https://github.com/gravitystorm/openstreetmap-carto/issues/2663).

Although this decision was already overdue back then mappers obviously 
also continued to use the old form of tagging afterwards in some cases. 
But it is the task of the standard style to support mappers in their 
decision to use relations as the primary form of mapping boundaries - 
which has very wide support in the mapper community because it is 
immediately obvious to most that this is a much more efficient and less 
error prone way to map boundaries.  This is a completely normal process 
in OSM - just like with old style multipolygon tagging, wood=* vs. 
leaf_type/leaf_cycle or highway=ford vs. ford=yes.

For clarification in terms of mapping - current consensus seems to be 
that:

* mapping a boundary with way tagging only without a boundary relation 
is wrong.
* mapping a boundary with relation tagging only with no tags on the way 
is correct.
* tagging the ways in addition to the relation is ok but not required.
* tagging on boundary relations superseedes any conflicting tagging on 
boundary ways.

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

[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: 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: 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: 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: 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: 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 <colin.sm...@xs4all.nl> 
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 
<mailto: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 <t.pfei...@computer.org>
> 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