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,
boun
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
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
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
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
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
represen
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 differe
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
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 codifi
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 ava
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 int
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
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 boundari
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
> * R
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 high
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
DaveF made a really good point : boundary:administration=maritime (or something
similar)?
At least I expect those ways to deserve a particular tag as they are almost
certainly special in many respects.
Sincerely, the original idea to mass tag ways part of any boundary level for
ease of render
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/mariti
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 deter
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
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 b
On Fri, Mar 9, 2018 at 7:51 PM, Matthijs Melissen
wrote:
> A map showing admin boundary ways without admin_level tag (displayed
> in gray) can be found here:
> http://product.itoworld.com/map/2?lon=20.00736&lat=51.92203&zoom=6
> As can be seen, most countries already do have admin_level on ways.
>
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=y
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 **
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. Th
On 2018-03-11 00:37, Eugene Alvin Villar wrote:
> On Sun, Mar 11, 2018 at 12:41 AM, André Pirard
> mailto:a.pirard.pa...@gmail.com>> wrote:
>
> Hi all,
>
> Please all, take a very attentive look at this.
> Please note the subject change: unnecessary.
> Please note the disambiguation
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 & p
27 matches
Mail list logo
