Re: [Tagging] Feature Proposal - RFC - Mapping disputed boundaries

[Johnparis]

After looking at the feedback, I have had a major realization that I think
makes the proposal much more viable while not adding innumerable new
relations.

Please see:
https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Mapping_disputed_boundaries#.22Disputed_Area.22_and_.22Zone_of_Control.22

Briefly, the idea is to divide the world into Disputed Areas (with possible
subareas of Zones of Control), along with the notion of a "Lesser
(countryname)" which can be thought of as a rump version of the country
minus all its disputed areas.

So, specifically in the case of Crimea, you would have:

Disputed Area: Crimea
claimed_by: RU;UA
acceptance:claim:FR=UA
acceptance:claim:PK=neutral
acceptance:claim:AF=RU
...etc...

Zones of Control: 1
Zone #1
controlled_by=RU

The referenced link goes into more detail and provides a simple algorithm
for creating maps of the world from different points of view.

John



On Tue, Nov 27, 2018 at 1:20 PM Johnparis  wrote:

> Thank you for that reference, Marc.
>
> The blog post you cite deals with the policy and how it is enforced, not
> with the question of physical control. The blog acknowledges that Russia
> has physical control.
>
> Let me be clear: this proposal makes NO CHANGES in the existing policy
> regarding de facto borders, and makes NO CHANGES in how that policy is
> implemented (other than to explicitly tag borders where OSMF has made a
> ruling).
>
> Discussions of the existing policy and its enforcement are therefore not
> on topic. I personally have issues with the policy (it has led to, shall we
> say, rather "unique" maps in many parts of the world), but those are
> properly directed at the OSMF and the DWG. They are not relevant to this
> proposal.
>
> This proposal offers a mechanism, if you will, for the "losing side" in a
> ruling by the OSMF to "have its say" on the map. It does not absolve OSMF
> from its role in making a ruling.
>
> The proposal works regardless of how OSMF decides to enforce (or change)
> its policy. Hypothetically, OSMF could decide that henceforth, all de facto
> borders will be taken from the 1923 Atlas of the World by Encyclopaedia
> Britannica. (That would lift one burden from them!) This proposal would
> remain the same.
>
> John
>
>
>
>
> On Tue, Nov 27, 2018 at 10:20 AM Marc Gemis  wrote:
>
>> On Tue, Nov 27, 2018 at 10:06 AM Johnparis  wrote:\
>>
>> > The question of "physical control" is, I believe, not at issue. The
>> fact that Russia exercises physical control is precisely what Ukraine
>> objects to. So both sides agree that Russia has physical control of
>> Ukraine. But if there were a dispute, again from the proposal: Disputes
>> about which claiming entity, if any, exercises control over a particular
>> territory can be resolved by the OSM Institutions (meaning the OSMF or the
>> DWG). The criterion of "most widely internationally recognised", and how it
>> might conflict with the criterion of "best meets realities on the ground",
>> is at issue. So the de facto situation remains one that the OSM
>> Institutions would have to resolve. When resolved, the de facto border
>> would get the "boundary:status=osm_designated" tag, which essentially makes
>> it "not subject to change" (by ordinary mappers, anyway).
>>
>> From https://www.openstreetmap.org/user/Kilkenni/diary/47017#comment43421
>> I understand that the notion using  "physical control" to define the
>> border is the problem.
>>
>> m.
>>
>> ___
>> 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] My proposal for disputed country borders

[Rory McCann]

(Some of this is on the wiki)

On 28/11/2018 06:39, Johnparis wrote:
I don't think the notion of "according_to" is viable unless it is 
restricted to the two disputing parties. (Three-way disputes can be 
simplified into three two-way disputes.)


This is why I like according_to:XX=yes/no. It allows for many options, 
not just 2.


I'll also look at your proposed tag (boundary=claimed_administrative) 
vs. my proposed tag (boundary_claim=administrative). Not sure whether 
there's any significant difference in implementation, but would like 
your thoughts on that.


boundary=claimed_administrative say "this is a boundary and it's of this 
type".


I plan to rethink my proposal along these lines. One problem I now see 
with my examples, for instance, is that it provides relations for SADR 
(de facto and claimed) and MA (de facto and claimed), but not MA as seen 
by SADR. So you can't draw a global map from these relations from the 
viewpoint of SADR and its supporters. (You can do one from the viewpoint 
of MA, because SADR doesn't exist in that world, but that's a special case.)


I suspect "Country X thinks country Y doesn't really exist" is very 
common, surely it must happen when a region secedes. I suspect Turkish 
Republic of North Cyprus doesn't exist as a country according to Cyprus 
or Italy, or Taiwan isn't a separate country according to China. 
Kosovo isn't a separate country according to Serbia. etc. 
"according_to:XX=no" can be useful here.


Finally, is there some reason you want to create a competing proposal? I 
don't have any knowledge of two competing proposals being discussed at 
the same time; would they be followed by two votes? I thought the idea 
was to reach consensus.


Yes this can appear a little snarky, that's not my intent. I half 
heartely suggested this idea 2 years ago ( 
https://lists.openstreetmap.org/pipermail/tagging/2016-May/029211.html 
), but abandoned it.


As you know, recent events mean OSM should have an answer to this. We'll 
talk and discuss and surely we can come to consensus.



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

Re: [Tagging] Feature Proposal - Voting - boundary=aboriginal_lands

[Paul Allen]

On Wed, Nov 28, 2018 at 1:55 AM Doug Hembry  wrote:

>
> Everyone seems to have forgotten boundary=administrative with its
> associated admin_level=n tag, which IMHO is pretty analogous to
> boundary=protected_area with its protect_class=n tag.


I didn't forget it.  I neglected to mention it because I didn't feel like
opening both ends of a
can of worms and figured one end was enough.  Now that you raise the issue,
I don't like the
numbers in admin_level, but at least they are sort of hierarchical, whereas
protect_class is not,
and there are very few of them.

They even both have look-up tables by country. And the class numbers are
> not arbitrary,
> Mateusz, - they map to IUCN categories.
>

That wasn't clear to me from the documentation.  I inferred that might be
the case but I
didn't see an explicit mention.  Then again, there is way too much
documentation to wade
through before I saw a mention of IUCN at all.  That ought to have been
made clear in the
introduction, probably the first paragraph of the introduction, and maybe
the first sentence
of that paragraph.  But that still wouldn't redeem it.

But seriously, how many aboriginal lands do you think a mapper would
> have to tag before they remember "protect_class=24"?
>

How many mappers handle nothing but aboriginal lands?  Are there so many
aboriginal lands
that even one mapper could deal with those and have time for nothing else?
I'd guess that most
mappers try to deal with everything in a locality they're mapping.  But
protected areas are rare
and you're asking people to remember ALL of those magic numbers in case
they come across
a nature reserve, or aboriginal land, or any of dozens of other things.


> And, as for the future archaeologists, and "human readable": Correct use
> of the boundary=protected_area tag actually requires the use of
> protect_title=* tag that provides users with the human readable title of
> this area-type (note: not the "name", which may also be present). ie,
> protect_title= Indigenous Protected Areas, or Indian Reservations, or
> Terra Indigena, or Territorio Indigena, etc,..


The protect_title is duplicating information in the class.  So you're
asking a mapper to type in
(and possibly get wrong) what should be a look-up mechanism.  Either
protect_title is unnecessary
or protect_class is.  Unless, of course, protect_class is so broad that
protect_title is needed to
flesh it out, in which case protect_class is useless.


> But although I don't buy your "numbers are bad" argument [...]
>

Numbers are bad.  Not always, of course.  building:levels is numeric.  Most
house numbers are
purely numeric (only most, because of things like 12A).  But magic numbers,
which IUCN are,
are bad in a human interface.  They are a good way of reducing storage in a
database (at the
expense of compute resources) so might be appropriate there, hidden from
the eyes of all but
the database coders.

What you're asking for means that, to make the thing human-friendly, EVERY
editor has to have a
look-up table so mappers can be presented with a list of comprehensible
choices like "aboriginal
lands" which get mapped to protect_class=24.  What you're asking for is
that EVERY data consumer
has to have a look-up table so humans get to see that an area on the map is
aboriginal land rather
than protect_class=24.  Technically, it's possible; realistically it won't
get implemented in all
applications.

The "numbers are bad" assertion worries me and prompts a broader question:
> if this is "policy",


It is not (as far as I am aware) a policy.  It is the feeling of a number
of people here that magic
numbers are a bad idea.  I suspect that many of those people base that
feeling, as I do, upon
experience of programming and/or user interface design.


> does it mean that boundary=protected_area, and protect_class=* tags are
> doomed in OSM?


I wouldn't say they're doomed, but I doubt they'll get universal adoption
as the primary way of
tagging such things, particularly if tags such as aboriginal_lands gain
approval.  This discussion
isn't the first time I came across protect_class etc.  Some time ago I
looked at how to map a
nature reserve and saw the choices were incomprehensible mess of
protect_class and friends
or leisure=nature_reserve.  Guess which one I chose.

I have no objection whatsoever if you wanted to introduce a tag like
IUCN=*.  In fact, I think it
would be a great idea.  Mappers who care about it could use it.  Queries
with overpass-turbo
could use it.  Nice idea.  But protect_class and friends?  Nah.

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

Re: [Tagging] Feature Proposal - RFC - Mapping disputed boundaries

[Martin Koppenhoefer]

what about observers to the UN, e.g. Palestine?

https://en.m.wikipedia.org/wiki/United_Nations_General_Assembly_observers

https://en.m.wikipedia.org/wiki/State_of_Palestine

Or Kurdistan, which doesn’t exist as a country, but there is a people and 
claims for a country (verifiability of claimed borders could well be an issue 
here)
https://en.m.wikipedia.org/wiki/Kurdistan

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

Re: [Tagging] Feature Proposal - RFC - Mapping disputed boundaries

[Johnparis]

Thanks for that, Martin. This is explicitly covered in the proposal under
the List of Claiming Entities. The criteria for joining the list are
crucial to implementation of the proposal.

Palestine is on the list. Kurdistan is not. But once again, it's the
criteria that count.


On Wed, Nov 28, 2018 at 1:46 PM Martin Koppenhoefer 
wrote:

> what about observers to the UN, e.g. Palestine?
>
> https://en.m.wikipedia.org/wiki/United_Nations_General_Assembly_observers
>
> https://en.m.wikipedia.org/wiki/State_of_Palestine
>
> Or Kurdistan, which doesn’t exist as a country, but there is a people and
> claims for a country (verifiability of claimed borders could well be an
> issue here)
> https://en.m.wikipedia.org/wiki/Kurdistan
>
> Cheers, Martin
> ___
> 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] Feature Proposal - RFC - Mapping disputed boundaries

[Johnparis]

Based on the feedback I have received so far, I plan to refine the Proposed
Feature. I still welcome comments during this period, but I think the
revised version will go a long way to resolving the problems we currently
face. (For a hint, see my latest remarks on the Talk page of the proposal.)

I hope to have the revised version (with examples) ready by the weekend.

John


On Wed, Nov 28, 2018 at 2:04 PM Johnparis  wrote:

> Thanks for that, Martin. This is explicitly covered in the proposal under
> the List of Claiming Entities. The criteria for joining the list are
> crucial to implementation of the proposal.
>
> Palestine is on the list. Kurdistan is not. But once again, it's the
> criteria that count.
>
>
> On Wed, Nov 28, 2018 at 1:46 PM Martin Koppenhoefer <
> dieterdre...@gmail.com> wrote:
>
>> what about observers to the UN, e.g. Palestine?
>>
>> https://en.m.wikipedia.org/wiki/United_Nations_General_Assembly_observers
>>
>> https://en.m.wikipedia.org/wiki/State_of_Palestine
>>
>> Or Kurdistan, which doesn’t exist as a country, but there is a people and
>> claims for a country (verifiability of claimed borders could well be an
>> issue here)
>> https://en.m.wikipedia.org/wiki/Kurdistan
>>
>> Cheers, Martin
>> ___
>> 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] Feature Proposal - Voting - boundary=aboriginal_lands

[Doug Hembry]

On 11/28/18 11:49, Joseph Eisenberg wrote:
No need for conspiracy theories. We simply need more contributors at 
openstreetmap-carto who are willing to volunteer their time to fix these 
issues. But we are about to start rendering the equivalent protected_class 
boundaries for national parks and nature reserves in the next release, this 
month
and On 11/28/18 04:12, Daniel Koć wrote:
It took me a lot of time and effort to compare them with nature reserves and 
national parks, trying to find some common ground, so I had enough of it for 
over a year... However there seems to be no clear rule to convert, so when 
someone nudged me lately, I just did the rest of a dirty work with the code and 
now it awaits for the comments (or approval of some other collaborator) and, 
hopefully, next release. That's all story. We really do need more coders. With 
~350 open tickets there's still a lot of work for everyone.

Hi Joseph and Daniel,
This is great news... Thank you both so much! (and to the whole carto team!) I 
guess I hadn't appreciated that it would be a difficult change, from a position 
of total ignorance it sounded pretty straightforward - obviously I shouldn't 
jump to conclusions.

The point is taken about the workload and lack of coders. It has always amazed 
me that the team manages to produce a robust, attractive and coherent map from 
the disparate tagging styles and sometime slightly weird practices that can be 
found in the database (I'd love to help but I think my coding years are behind 
me). This forthcoming change will make mapping life a lot easier around here, 
and probably in a lot of other regions, and we can now go back and clean up 
some of the questionable "tagging for the renderer" that has accumulated over 
recent years around this topic.

I'm sorry if my slightly hysterical posts were over the top. No offense 
intended. Perhaps I should see someone about my paranoid tendencies:-) I also 
realize that these kinds of mailing list discussions are a distraction from the 
real work. Sorry!

Thanks very much, again..
Cheers
Doug Hembry

PS: (I can't resist) If you guys wanted to burnish your already hero status 
in 2019, it would be really helpful to have the boundary=protected_area 
rendering differentiate "closed" areas (based on the access tag) as is done for 
roads today. A simple dashed rendering would probably suffice. But maybe I 
should wait for the forthcoming change first, and then teach myself how to 
raise an issue on github in the approved manner.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - Voting - boundary=aboriginal_lands

[Daniel Koć]

W dniu 28.11.2018 o 17:23, Doug Hembry pisze:

> The point is taken about the workload and lack of coders. It has
> always amazed me that the team manages to produce a robust, attractive
> and coherent map from the disparate tagging styles and sometime
> slightly weird practices that can be found in the database (I'd love
> to help but I think my coding years are behind me).


This is complex process and don't worry - coding is typically not the
hardest part of it. Analysing the meaning of tagging schemes, and how
they are used, is a common part of preparing rendering. Also finding
clear design, which is not in conflict with something we already show,
can be difficult.

Trying to be back on topic: this thread is good illustration of such
process. It looks like the code for boundary=protected_area (restricted
only to natural resources) was a reason to prepare similar code for both
boundary=aboriginal_lands and boundary=protected_area +
protect_class=24. That would be easy to just merge, but we were not sure
how they relate to each other, and one of them was not even documented.
Now we are trying to figure out the proper tagging on this list and at
the same time we're also trying to get the proper rendering, since
proposed rendering is similar to some other (namely zoo) and we render
so many objects, that it's hard to find something distinct and clear.

So, we have both tagging scheme and rendering problems here and we need
some decisions, even if the actual code is already there.


> I'm sorry if my slightly hysterical posts were over the top. No
> offense intended. Perhaps I should see someone about my paranoid
> tendencies:-) I also realize that these kinds of mailing list
> discussions are a distraction from the real work. Sorry!


No offence taken. :-) I try to make people aware how tagging and
rendering (I know just OSM Carto style) are related to each other and
this was a good opportunity to speak out. OSM is so big ecosystem, that
it's quite common that different projects do not even communicate, which
is really bad for the whole community.


> PS: (I can't resist) If you guys wanted to burnish your already
> hero status in 2019, it would be really helpful to have the
> boundary=protected_area rendering differentiate "closed" areas (based
> on the access tag) as is done for roads today. A simple dashed
> rendering would probably suffice. But maybe I should wait for the
> forthcoming change first, and then teach myself how to raise an issue
> on github in the approved manner.


This is one of the ideas to discuss on OSM Carto issue tracker. Please
join and you will see how designing process really works. The only
trivial changes are typos, most of the other propositions need some time
and discussion.


-- 
"Excuse me, I have some growing up to do" [P. Gabriel]



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

Re: [Tagging] Suggestion: ref:mobile_payment for amenity=parking

[bkil]

payment:sms=yes
payment:WhateverPayApp=yes
contact:sms=
ref:payment=

As an alternative, ref:sms=* would also work for me, though I think
it's redundant if the code is the same for all payment options.
ref:payment:sms=* sounds a bit excessive, but would be the most
correct tagging. However, OSM strives for consistency and
mapper-friendliness more than "correct" tagging in most cases, so I.

I would definitely mark the exact payment variety, like

* payment:sms=*,
* payment:app=* or even better payment:WhateverPayApp=*,
* payment:mastercard_contactless=*.

I don't recommend using payment:pay_by_phone=* or
payment:contactless=* due to the sheer number of incompatible
different payment solutions (see wiki). It sounds worse to me than
payment:debit_cards=* that many disapprove of, while I do use
payment:debit_cards=* myself. I actually wanted to bring this up in a
new topic recently:

>> payment:contactless=*
Contactless payment on Wikipedia and Contactless smart card on Wikipedia
Used to indicate that a venue has 'contactless' (RFID/NFC-based) bank
card readers. You may consider adding the precise variety of
contactless smart card accepted: payment:expresspay=*,
payment:mastercard_contactless=* (formerly payment:paypass=*),
payment:visa_contactless=* (alternatively payment:paywave=*),
payment:quickpass=*, payment:quicpay=* (overseas J/Speedy, commonly
payment:QUICPay=*), payment:rupay_contactless=*, payment:zip=*,
payment:mifare=*
(wikipedia:en:MIFARE#Places_that_use_MIFARE_products),
payment:felica=*(wikipedia:en:FeliCa#Card_usage), payment:wechat=*
(wikipedia:en:WeChat#WeChat_Pay_payment_services), payment:alipay=*
(wikipedia:en:Alipay#Comparison_with_other_payment_systems),
payment:venmo=*. Not to be confused with contactless electronic
variants of payment:meal_vouchers=* and payment:electronic_purses=*
that are used in-house at many places. <<

On Thu, Nov 22, 2018 at 9:29 AM Philip Barnes  wrote:
>
>
>
> On 21 November 2018 12:45:30 GMT, Michael Brandtner 
>  wrote:
> >Philip Barnes  schrieb am 23:29 Dienstag,
> >20.November 2018:
> >
> >> I am not 100% sure that mobile payment is the correct term, that to
> >me implies using your phone for contactless payment.
> >But wouldn't that be payment:contactless?
> >
> >> The English term used in these cases is Pay by Phone.
> >So your suggestion is payment:pay_by_phone and ref:pay_by_phone?
>
> That is correct, pay by phone is the normal English usage.
>
> Phil (trigpoint)
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>
> ___
> 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] Suggestion: ref:mobile_payment for amenity=parking

[Sergio Manzi]

Sorry, but it should be:

payment:sms=yes
payment:sms:WhateverPayApp=yes
payment:sms:WhateverPayApp:contact=
payment:sms:WhateverPayApp:ref:payment=

because, sooner or later, multiple payment options/clearingouse/apps could be 
supported and each should have its info.

The "ref:" could be go, IMHO...

Cheers,

Sergio Manzi


On 2018-11-28 21:07, bkil wrote:
> payment:sms=yes
> payment:WhateverPayApp=yes
> contact:sms=
> ref:payment=
>
> As an alternative, ref:sms=* would also work for me, though I think
> it's redundant if the code is the same for all payment options.
> ref:payment:sms=* sounds a bit excessive, but would be the most
> correct tagging. However, OSM strives for consistency and
> mapper-friendliness more than "correct" tagging in most cases, so I.
>
> I would definitely mark the exact payment variety, like
>
> * payment:sms=*,
> * payment:app=* or even better payment:WhateverPayApp=*,
> * payment:mastercard_contactless=*.
>
> I don't recommend using payment:pay_by_phone=* or
> payment:contactless=* due to the sheer number of incompatible
> different payment solutions (see wiki). It sounds worse to me than
> payment:debit_cards=* that many disapprove of, while I do use
> payment:debit_cards=* myself. I actually wanted to bring this up in a
> new topic recently:
>
>>> payment:contactless=*
> Contactless payment on Wikipedia and Contactless smart card on Wikipedia
> Used to indicate that a venue has 'contactless' (RFID/NFC-based) bank
> card readers. You may consider adding the precise variety of
> contactless smart card accepted: payment:expresspay=*,
> payment:mastercard_contactless=* (formerly payment:paypass=*),
> payment:visa_contactless=* (alternatively payment:paywave=*),
> payment:quickpass=*, payment:quicpay=* (overseas J/Speedy, commonly
> payment:QUICPay=*), payment:rupay_contactless=*, payment:zip=*,
> payment:mifare=*
> (wikipedia:en:MIFARE#Places_that_use_MIFARE_products),
> payment:felica=*(wikipedia:en:FeliCa#Card_usage), payment:wechat=*
> (wikipedia:en:WeChat#WeChat_Pay_payment_services), payment:alipay=*
> (wikipedia:en:Alipay#Comparison_with_other_payment_systems),
> payment:venmo=*. Not to be confused with contactless electronic
> variants of payment:meal_vouchers=* and payment:electronic_purses=*
> that are used in-house at many places. <<
>
> On Thu, Nov 22, 2018 at 9:29 AM Philip Barnes  wrote:
>>
>>
>> On 21 November 2018 12:45:30 GMT, Michael Brandtner 
>>  wrote:
>>> Philip Barnes  schrieb am 23:29 Dienstag,
>>> 20.November 2018:
>>>
 I am not 100% sure that mobile payment is the correct term, that to
>>> me implies using your phone for contactless payment.
>>> But wouldn't that be payment:contactless?
>>>
 The English term used in these cases is Pay by Phone.
>>> So your suggestion is payment:pay_by_phone and ref:pay_by_phone?
>> That is correct, pay by phone is the normal English usage.
>>
>> Phil (trigpoint)
>> --
>> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - Voting - boundary=aboriginal_lands

[Paul Johnson]

On Wed, Nov 28, 2018 at 5:59 AM Paul Allen  wrote:

>
> On Wed, Nov 28, 2018 at 1:55 AM Doug Hembry 
> wrote:
>
>> But seriously, how many aboriginal lands do you think a mapper would
>> have to tag before they remember "protect_class=24"?
>>
>
> How many mappers handle nothing but aboriginal lands?  Are there so many
> aboriginal lands
> that even one mapper could deal with those and have time for nothing
> else?  I'd guess that most
> mappers try to deal with everything in a locality they're mapping.  But
> protected areas are rare
> and you're asking people to remember ALL of those magic numbers in case
> they come across
> a nature reserve, or aboriginal land, or any of dozens of other things.
>

I'd imagine this is considerably more common in Oklahoma and the desert
southwest than most places, it's quite a long drive to get out of
aboriginal lands from where I live.  As a result, HDYC shows that my area
of primary focus  is entirely
within the Osage Nation
,
Cherokee
Nation  and Muscogee Nation
.  You basically have to
stay north of Fort Sill and west of I 35 (to greatly oversimplify complex
boundaries) to stay away from aboriginal lands in Oklahoma.

And, as for the future archaeologists, and "human readable": Correct use
>> of the boundary=protected_area tag actually requires the use of
>> protect_title=* tag that provides users with the human readable title of
>> this area-type (note: not the "name", which may also be present). ie,
>> protect_title= Indigenous Protected Areas, or Indian Reservations, or
>> Terra Indigena, or Territorio Indigena, etc,..
>
>
> The protect_title is duplicating information in the class.  So you're
> asking a mapper to type in
> (and possibly get wrong) what should be a look-up mechanism.  Either
> protect_title is unnecessary
> or protect_class is.  Unless, of course, protect_class is so broad that
> protect_title is needed to
> flesh it out, in which case protect_class is useless.
>

Not to mention in practice, this is something of a misnomer for most tribes
in the US.  WaPo has an op-ed

about a pending SCOTUS case on this, that has a nonzero chance of redrawing
state lines and affecting national autonomy for tribes..


> The "numbers are bad" assertion worries me and prompts a broader question:
>> if this is "policy",
>
>
> It is not (as far as I am aware) a policy.  It is the feeling of a number
> of people here that magic
> numbers are a bad idea.  I suspect that many of those people base that
> feeling, as I do, upon
> experience of programming and/or user interface design.
>
>
>> does it mean that boundary=protected_area, and protect_class=* tags are
>> doomed in OSM?
>
>
> I wouldn't say they're doomed, but I doubt they'll get universal adoption
> as the primary way of
> tagging such things, particularly if tags such as aboriginal_lands gain
> approval.  This discussion
> isn't the first time I came across protect_class etc.  Some time ago I
> looked at how to map a
> nature reserve and saw the choices were incomprehensible mess of
> protect_class and friends
> or leisure=nature_reserve.  Guess which one I chose.
>
> I have no objection whatsoever if you wanted to introduce a tag like
> IUCN=*.  In fact, I think it
> would be a great idea.  Mappers who care about it could use it.  Queries
> with overpass-turbo
> could use it.  Nice idea.  But protect_class and friends?  Nah.
>

As an aside, no, I'm not married to how those nations are tagged right now,
it's just where we seemed to be at after the last time this came up.  I
think it's a messy hack and not orthagonal to being readily human
understandable.  I can talk to my sister who knows next to nothing about
OSM other than Craigslist uses it, ask her what highway=primary likely is,
and get either a good answer or a spot-on answer.  If I asked her about
protect_class=24, I'm pretty sure she'd be dumbfounded.  Plus it falls into
a part of the complaints I had the first time it came up
.
Given the context of what I'm familiar with, it's actually amazing to me we
haven't put this in the boundary=administrative column as we have with
other political boundaries.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - Voting - boundary=aboriginal_lands

[Mateusz Konieczny]

28. Nov 2018 19:45 by dan...@xn--ko-wla.pl :


> W dniu 28.11.2018 o 17:23, Doug Hembry pisze:
>
>> The point is taken about the workload and lack of coders. It has
>> always amazed me that the team manages to produce a robust, attractive
>> and coherent map from the disparate tagging styles and sometime
>> slightly weird practices that can be found in the database (I'd love
>> to help but I think my coding years are behind me).
>
>
> This is complex process and don't worry - coding is typically not the
> hardest part of it. Analysing the meaning of tagging schemes, and how
> they are used, is a common part of preparing rendering. Also finding
> clear design, which is not in conflict with something we already show,
> can be difficult.
>




And there is one more time-consuming part: 




testing across diverse locations whatever given styling works well (or at least 
is it

acceptable).




For example in case of 
https://github.com/gravitystorm/openstreetmap-carto/pull/1736 


I would estimate effort to go roughly




- 1% setup (as most of the development environment was already existing)


- 5% researching tagging (as roads tagging is relatively well established)

- 10% researching other maps


- 5% coding

- 10% testing whatever my code works as expected

- 40% testing whatever rendering works well, tweak colour/width/zoom settings 
and repeat


- 24% communication (via diary, issues, pull requests, mails etc)

- 4% asking others what is their comment of given style


- 1% administrative GSoC overhead




note: "collecting new ideas for styling" is not appearing above as there was no 
dedicated

time for that (except "researching other maps"), I noted new ideas as they 
appeared

during other tasks or during day.





beware: it was 3 years ago, and this is based on my memories

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

Re: [Tagging] Feature Proposal - Voting - boundary=aboriginal_lands

[Graeme Fitzpatrick]

On Thu, 29 Nov 2018 at 07:22, Paul Johnson  wrote:

> WaPo has an op-ed
> 
> about a pending SCOTUS case on this, that has a nonzero chance of redrawing
> state lines and affecting national autonomy for tribes..
>

Very interesting article thanks, Paul - any idea on possible time frame to
get a decision?

Thanks

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

Re: [Tagging] Feature Proposal - Voting - boundary=aboriginal_lands

[Doug Hembry]

On Wed, Nov 28, 2018 at 11:55 AM Paul Allen wrote:


Everyone seems to have forgotten boundary=administrative with its associated 
admin_level=n tag, which IMHO is pretty analogous to boundary=protected_area 
with its protect_class=n tag.
I didn't forget it. I neglected to mention it because I didn't feel like 
opening both ends of a can of worms and figured one end was enough. Now that 
you raise the issue, I don't like the numbers in admin_level, but at least they 
are sort of hierarchical, whereas protect_class is not, and there are very few 
of them. They even both have look-up tables by country. And the class numbers 
are
not arbitrary, Mateusz, - they map to IUCN categories.
That wasn't clear to me from the documentation. I inferred that might be the 
case but I didn't see an explicit mention. Then again, there is way too much 
documentation to wade through before I saw a mention of IUCN at all. That ought 
to have been made clear in the introduction, probably the first paragraph of 
the introduction, and maybe the first sentence of that paragraph. But that 
still wouldn't redeem it. But seriously, how many aboriginal lands do you think 
a mapper would
have to tag before they remember "protect_class=24"?
How many mappers handle nothing but aboriginal lands? Are there so many 
aboriginal lands that even one mapper could deal with those and have time for 
nothing else? I'd guess that most mappers try to deal with everything in a 
locality they're mapping. But protected areas are rare and you're asking people 
to remember ALL of those magic numbers in case they come across a nature 
reserve, or aboriginal land, or any of dozens of other things.
And, as for the future archaeologists, and "human readable": Correct use of the 
boundary=protected_area tag actually requires the use of protect_title=* tag 
that provides users with the human readable title of this area-type (note: not 
the "name", which may also be present). ie, protect_title= Indigenous Protected 
Areas, or Indian Reservations, or Terra Indigena, or Territorio Indigena, etc,..
The protect_title is duplicating information in the class. So you're asking a 
mapper to type in (and possibly get wrong) what should be a look-up mechanism. 
Either protect_title is unnecessary or protect_class is. Unless, of course, 
protect_class is so broad that protect_title is needed to flesh it out, in 
which case protect_class is useless.
But although I don't buy your "numbers are bad" argument [...]
Numbers are bad. Not always, of course. building:levels is numeric. Most house 
numbers are purely numeric (only most, because of things like 12A). But magic 
numbers, which IUCN are, are bad in a human interface. They are a good way of 
reducing storage in a database (at the expense of compute resources) so might 
be appropriate there, hidden from the eyes of all but the database coders. What 
you're asking for means that, to make the thing human-friendly, EVERY editor 
has to have a look-up table so mappers can be presented with a list of 
comprehensible choices like "aboriginal lands" which get mapped to 
protect_class=24. What you're asking for is that EVERY data consumer has to 
have a look-up table so humans get to see that an area on the map is aboriginal 
land rather than protect_class=24. Technically, it's possible; realistically it 
won't get implemented in all applications. The "numbers are bad" assertion 
worries me and prompts a broader question:
if this is "policy",
It is not (as far as I am aware) a policy. It is the feeling of a number of 
people here that magic numbers are a bad idea. I suspect that many of those 
people base that feeling, as I do, upon experience of programming and/or user 
interface design.
does it mean that boundary=protected_area, and protect_class=* tags are doomed 
in OSM?
I wouldn't say they're doomed, but I doubt they'll get universal adoption as 
the primary way of tagging such things, particularly if tags such as 
aboriginal_lands gain approval. This discussion isn't the first time I came 
across protect_class etc. Some time ago I looked at how to map a nature reserve 
and saw the choices were incomprehensible mess of protect_class and friends or 
leisure=nature_reserve. Guess which one I chose. I have no objection whatsoever 
if you wanted to introduce a tag like IUCN=*. In fact, I think it would be a 
great idea. Mappers who care about it could use it set. Queries with 
overpass-turbo could use it. Nice idea. But protect_class and friends? Nah.
-- Paul

Hi Paul,
If I've interpreted TagInfo correctly, worldwide uses of the 
boundary=protected_area tag set are:
boundary=protected_area73k
boundary=protected area with protect_class=*42k
boundary=protected area with protection_title35k

So apparently a lot of people are happy to use boundary=protected_area. As 
things stand at the moment, if you don't use it, and/or you want your mapping 
to render, you pretty much h

Re: [Tagging] Feature Proposal - Voting - boundary=aboriginal_lands

[Paul Johnson]

On Wed, Nov 28, 2018 at 4:24 PM Graeme Fitzpatrick 
wrote:

>
> On Thu, 29 Nov 2018 at 07:22, Paul Johnson  wrote:
>
>> WaPo has an op-ed
>> 
>> about a pending SCOTUS case on this, that has a nonzero chance of redrawing
>> state lines and affecting national autonomy for tribes..
>>
>
> Very interesting article thanks, Paul - any idea on possible time frame to
> get a decision?
>

Probably by the time the current Supreme Court session ends in spring.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - Voting - boundary=aboriginal_lands

[Paul Johnson]

Not to say that tag popularity means it's the best way forward.  Consider
that the US is still dealing with an import on low quality TIGER data and
continent-wide smash-tagging by one person affecting how newer people use
highway=motorway and highway=trunk.

On Wed, Nov 28, 2018 at 5:09 PM Doug Hembry  wrote:

> On Wed, Nov 28, 2018 at 11:55 AM Paul Allen wrote:
>
> Everyone seems to have forgotten boundary=administrative with its
> associated admin_level=n tag, which IMHO is pretty analogous to
> boundary=protected_area with its protect_class=n tag.
>
> I didn't forget it. I neglected to mention it because I didn't feel like
> opening both ends of a can of worms and figured one end was enough. Now
> that you raise the issue, I don't like the numbers in admin_level, but at
> least they are sort of hierarchical, whereas protect_class is not, and
> there are very few of them. They even both have look-up tables by country.
> And the class numbers are
>
> not arbitrary, Mateusz, - they map to IUCN categories.
>
> That wasn't clear to me from the documentation. I inferred that might be
> the case but I didn't see an explicit mention. Then again, there is way too
> much documentation to wade through before I saw a mention of IUCN at all.
> That ought to have been made clear in the introduction, probably the first
> paragraph of the introduction, and maybe the first sentence of that
> paragraph. But that still wouldn't redeem it. But seriously, how many
> aboriginal lands do you think a mapper would
>
> have to tag before they remember "protect_class=24"?
>
> How many mappers handle nothing but aboriginal lands? Are there so many
> aboriginal lands that even one mapper could deal with those and have time
> for nothing else? I'd guess that most mappers try to deal with everything
> in a locality they're mapping. But protected areas are rare and you're
> asking people to remember ALL of those magic numbers in case they come
> across a nature reserve, or aboriginal land, or any of dozens of other
> things.
>
> And, as for the future archaeologists, and "human readable": Correct use
> of the boundary=protected_area tag actually requires the use of
> protect_title=* tag that provides users with the human readable title of
> this area-type (note: not the "name", which may also be present). ie,
> protect_title= Indigenous Protected Areas, or Indian Reservations, or Terra
> Indigena, or Territorio Indigena, etc,..
>
> The protect_title is duplicating information in the class. So you're
> asking a mapper to type in (and possibly get wrong) what should be a
> look-up mechanism. Either protect_title is unnecessary or protect_class is.
> Unless, of course, protect_class is so broad that protect_title is needed
> to flesh it out, in which case protect_class is useless.
>
> But although I don't buy your "numbers are bad" argument [...]
>
> Numbers are bad. Not always, of course. building:levels is numeric. Most
> house numbers are purely numeric (only most, because of things like 12A).
> But magic numbers, which IUCN are, are bad in a human interface. They are a
> good way of reducing storage in a database (at the expense of compute
> resources) so might be appropriate there, hidden from the eyes of all but
> the database coders. What you're asking for means that, to make the thing
> human-friendly, EVERY editor has to have a look-up table so mappers can be
> presented with a list of comprehensible choices like "aboriginal lands"
> which get mapped to protect_class=24. What you're asking for is that EVERY
> data consumer has to have a look-up table so humans get to see that an area
> on the map is aboriginal land rather than protect_class=24. Technically,
> it's possible; realistically it won't get implemented in all applications.
> The "numbers are bad" assertion worries me and prompts a broader question:
>
> if this is "policy",
>
> It is not (as far as I am aware) a policy. It is the feeling of a number
> of people here that magic numbers are a bad idea. I suspect that many of
> those people base that feeling, as I do, upon experience of programming
> and/or user interface design.
>
> does it mean that boundary=protected_area, and protect_class=* tags are
> doomed in OSM?
>
> I wouldn't say they're doomed, but I doubt they'll get universal adoption
> as the primary way of tagging such things, particularly if tags such as
> aboriginal_lands gain approval. This discussion isn't the first time I came
> across protect_class etc. Some time ago I looked at how to map a nature
> reserve and saw the choices were incomprehensible mess of protect_class and
> friends or leisure=nature_reserve. Guess which one I chose. I have no
> objection whatsoever if you wanted to introduce a tag like IUCN=*. In fact,
> I think it would be a great idea. Mappers who care about it could use it
> set. Queries with overpass-turbo could use it. Nice idea. But protect_class
> and friends? Nah.
> -- Paul
>
> Hi Paul,
> If I've interpreted TagInfo correctl

Re: [Tagging] Named walking tracks following road

[Andy Townsend]

On 28/11/2018 07:52, OSMDoudou wrote:
I would suggest to make a consistent edit of the area, not just solve 
one isolated MapRoulette challenge.




Yes.

Actually, in a case like that where someone's accidentally merged some 
names or other tags I'd suggest commenting on the changeset so that they 
know that you've fixed a problem.


Best Regards,

Andy



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

[Tagging] telescope types ... more type nonsense

[Warin]

Hi,

I have made changes to 
https://wiki.openstreetmap.org/wiki/Key:telescope:type


This again it a 'type' key that means???

I have taken it to be "broadly categorise the spectrum that the telescope 
sense".

Other problems ..

Solar telescope ... a special kind of optical telescope .. should this have its 
own entry?

I don't think so .. radio telescopes have a wide variety that show similar 
specialities, yet OSM does not distinguish between them here.

 



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

[Tagging] antenna use key to replace some of the antenna type

[Warin]

Hi,

Following from my previous post on antenna:type ..


This is the first of the antenna:* keys that could be used to categorise 
various 'types' of antennas.



https://wiki.openstreetmap.org/wiki/Proposed_features/antenna:use


This one is on the use to which the antenna signal is put.


It does need input on the values. And anything else of concern naturally.





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

Re: [Tagging] telescope types ... more type nonsense

[Michael Patrick]

> Other problems ..
>

  "A large fraction of such astronomical gamma rays are screened by Earth's
atmosphere." https://en.wikipedia.org/wiki/Gamma_ray#Sources
All done by satellite these days

And don't leave out neutrino telescopes

Be mindful of Z-order, I think Homestead was a mile underground.

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

Re: [Tagging] telescope types ... more type nonsense

[Joseph Eisenberg]

X-ray telescopes cannot be built on the ground, but there are several
recent gamma-ray telescope arrays. They are shaped like radio telescope
dishes, but the dish is polished like a huge shiny mirror; quite unique.
On Thu, Nov 29, 2018 at 10:31 AM Michael Patrick 
wrote:

>
> Other problems ..
>>
>
>   "A large fraction of such astronomical gamma rays are screened by
> Earth's atmosphere." https://en.wikipedia.org/wiki/Gamma_ray#Sources
> All done by satellite these days
>
> And don't leave out neutrino telescopes
> 
> Be mindful of Z-order, I think Homestead was a mile underground.
>
> Michael
> ___
> 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] Feature Proposal - Voting - boundary=aboriginal_lands

[Alan McConchie]

Paul,

I want to take your feedback with the weight and respect it deserves. I see you 
voted against "boundary=aboriginal_lands" on the wiki because you prefer 
"boundary=administrative". Can you clarify more about your proposed alternative?

In this thread I see you're a fan of admin_level=*, but what admin_level do you 
propose? The problem I see with that tag is that it follows a strict hierarchy, 
which reservations don't always follow. It's the hierarchical nature of 
boundary=administrative that I get hung up on, which is why I like that 
boundary=aboriginal_lands can exist parallel to that hierarchy.

For example, if we used boundary=administrative + admin_level=3 (as Kevin Kenny 
suggested in this thread) that seems clearly wrong for the few reservations 
that cross national boundaries, like Akwesasne.


Also more generally, to me the fact that boundary=aboriginal_lands doesn't have 
"administrative" in the name doesn't IMHO mean that it is not a legitimate 
political unit of administration. Arguably it expresses even greater autonomy 
and independence than some other tag that's shoe-horned into the 
boundary=administrative hierarchy. I can understand how others might see 
boundary=aboriginal_lands as a tag that carries less respect. But I don't see 
it that way.


Alan


> On Nov 27, 2018, at 6:44 AM, Paul Johnson  wrote:
> 
> 
> 
> On Tue, Nov 27, 2018, 07:10 Martin Koppenhoefer   wrote:
> 
> 
> sent from a phone
> 
> > On 27. Nov 2018, at 03:27, Paul Johnson  > > wrote:
> > 
> > I'm generally a fan of the admin_level option.  protected_area is OKisn, 
> > but the protect_class=* tag definitely hits me as an oddity given other 
> > tagging.  boundary=aboriginal_lands could be a supplemental tag to 
> > admin_level.
> 
> 
> +1, 
> admin_level is fine where it applies (maybe everywhere, not sure, it requires 
> the land to be an administrative entity which might not always be the case). 
> But it doesn’t tell you it is about land that the invaders gave to the native 
> population, so an additional tag is desirable.
> 
> I agree that protected_class is not sustainable (numbers as values are harder 
> to remember and easier to confuse).
> 
> The proposed boundary=aboriginal_lands seems quite ok. Would this be 
> combinable with admin_level, or would you insist on boundary=administrative? 
> The fact that both „main keys“ might apply sometimes seems to be a problem: 
> either you tag these as b=administrative and still haven’t said it is about 
> native population areas, or you use b=aboriginal_lands and as a result you 
> get administrative entities that are not tagged as b=administrative 
> 
> At least in the US and Canada, indian territories, reservations, reserves and 
> administrative areas are du jure administrative boundaries.
> ___
> 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] Feature Proposal - Voting - boundary=aboriginal_lands

[Paul Johnson]

On Wed, Nov 28, 2018 at 7:46 PM Alan McConchie 
wrote:

> I want to take your feedback with the weight and respect it deserves. I
> see you voted against "boundary=aboriginal_lands" on the wiki because you
> prefer "boundary=administrative". Can you clarify more about your proposed
> alternative?
>


> In this thread I see you're a fan of admin_level=*, but what admin_level
> do you propose? The problem I see with that tag is that it follows a strict
> hierarchy, which reservations don't always follow. It's the hierarchical
> nature of boundary=administrative that I get hung up on, which is why I
> like that boundary=aboriginal_lands can exist parallel to that hierarchy.
>
> For example, if we used boundary=administrative + admin_level=3 (as Kevin
> Kenny suggested in this thread) that seems clearly wrong for the few
> reservations that cross national boundaries, like Akwesasne.
>

I don't know if a consistent administrative level is possible given the
context of each particular tribe and it's respective relationship with the
US and Canada.  This may need to be determined on a case-by-case
situation.  I do think that admin_level=3 is a pretty reasonable in the US
because within tribal lands, if at least one party is a tribal citizen of
the nation they're in, I'm not aware of one that doesn't automatically
moves jurisdiction to tribal or federal courts *exclusively,* with state
and county courts not having jurisdiction.  In some cases, this might apply
to any criminal or civil case within the jurisdiction regardless of who is
involved.


> I can understand how others might see boundary=aboriginal_lands as a tag
> that carries less respect. But I don't see it that way.
>

Part of it is the strong tendency of folks making renders to fill-shade the
tribal territory like it's a park, wildlife preserve or zoo.  Carto used to
have a green "IR" hatch that was almost indistinguishable from the same
colored "NR" hatch for indian reservations (which was easily half of my
annoyance on the subject in 2013).  Treating tribal boundaries as other
political boundaries humanizes the situation.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - Voting - boundary=aboriginal_lands

[Joseph Eisenberg]

In California there are “End Freeway” signs, usually between the last
interchange and about 1/2 mike before the first at-grade intersection
On Thu, Nov 29, 2018 at 11:54 AM Paul Johnson  wrote:

> On Wed, Nov 28, 2018 at 7:46 PM Alan McConchie 
> wrote:
>
>> I want to take your feedback with the weight and respect it deserves. I
>> see you voted against "boundary=aboriginal_lands" on the wiki because you
>> prefer "boundary=administrative". Can you clarify more about your proposed
>> alternative?
>>
>
>
>> In this thread I see you're a fan of admin_level=*, but what admin_level
>> do you propose? The problem I see with that tag is that it follows a strict
>> hierarchy, which reservations don't always follow. It's the hierarchical
>> nature of boundary=administrative that I get hung up on, which is why I
>> like that boundary=aboriginal_lands can exist parallel to that hierarchy.
>>
>> For example, if we used boundary=administrative + admin_level=3 (as Kevin
>> Kenny suggested in this thread) that seems clearly wrong for the few
>> reservations that cross national boundaries, like Akwesasne.
>>
>
> I don't know if a consistent administrative level is possible given the
> context of each particular tribe and it's respective relationship with the
> US and Canada.  This may need to be determined on a case-by-case
> situation.  I do think that admin_level=3 is a pretty reasonable in the US
> because within tribal lands, if at least one party is a tribal citizen of
> the nation they're in, I'm not aware of one that doesn't automatically
> moves jurisdiction to tribal or federal courts *exclusively,* with state
> and county courts not having jurisdiction.  In some cases, this might apply
> to any criminal or civil case within the jurisdiction regardless of who is
> involved.
>
>
>> I can understand how others might see boundary=aboriginal_lands as a tag
>> that carries less respect. But I don't see it that way.
>>
>
> Part of it is the strong tendency of folks making renders to fill-shade
> the tribal territory like it's a park, wildlife preserve or zoo.  Carto
> used to have a green "IR" hatch that was almost indistinguishable from the
> same colored "NR" hatch for indian reservations (which was easily half of
> my annoyance on the subject in 2013).  Treating tribal boundaries as other
> political boundaries humanizes the situation.
> ___
> 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] Neighborhood Gateway Signs?

[AgusQui]

We consider it as generic for any type of entrance arch, be it in city,
neighborhood, etc.
Examples:
https://www.mapillary.com/app/?focus=photo&pKey=9abzbC1EpTRUE8R4PDYs5A&lat=-27.454227912298393&lng=-56.04909613175403&z=17

  
https://www.mapillary.com/app/?focus=photo&lat=-27.517409&lng=-55.161794&z=19.372836616796267&pKey=x9etmxQN1Kn89C2jjv9haQ&x=0.2902073459801868&y=0.5106450259144627&zoom=0

  
https://es.wikipedia.org/wiki/Archivo:Villa_Gesell_arco_entrada.jpg
  
city_entrance 


Joseph Eisenberg wrote
> Thank you, AgusQui. That sounds like a good option for an artistic
> entrance
> sign. Eg “Welcome to Fabulous Las Vegas.”
> 
> Can you give a link to photos of some of these?
> 
> But I don’t think artwork will work as a tag for simple overhead signs
> which don’t really qualify as artwork.
> 
> Also, city_entrance does not work well for signs in villages and
> neighborhoods, or signs that mark the center of a place rather than the
> entrance.
> 
> So it may still b necessary to make a new tag for these other situations
> On Tue, Nov 27, 2018 at 12:14 AM AgusQui <

> aguztinqui@

> > wrote:
> 
>> In Argentina we discussed this a few years ago and decided to use artwork
>> together with artwork_type = city_entrance
>> https://forum.openstreetmap.org/viewtopic.php?id=19718
>> ;
>>
>>
>>
>> --
>> Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html
>>
>> ___
>> Tagging mailing list
>> 

> Tagging@

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

> Tagging@

> https://lists.openstreetmap.org/listinfo/tagging





--
Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html

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

Re: [Tagging] Feature Proposal - Voting - boundary=aboriginal_lands

[Alan McConchie]

Ok, I see. So you propose that these areas should not have any additional tags 
that would identify them as special aboriginal areas, and that the admin_level 
should be chosen on a case-by-case basis depending on the circumstances of each 
area and the country that it's in?

And furthermore you don't want these areas to be styled differently from any 
other administrative boundaries? (and if we follow those tagging guidelines, no 
one would be _able_ to style them differently because they wouldn't have any 
special tags?) 

I expect that would mean we'd continue to have problems with people tagging for 
the renderer, as in Brazil, where people will tag native reservations as nature 
reserves to get them to show up prominently on the map. But if we provided an 
appropriate generic "administrative" boundary style for tagging native 
reservations, it's true that the tagging for the renderer would probably 
decrease, if not completely go away. 

In any case, no matter what tagging we settle on, I agree that we need a 
humanizing rendering that's not the same as zoo or nature reserve. But that's a 
topic for the ongoing discussion in the osm-carto github issue.

Alan

> On Nov 28, 2018, at 6:52 PM, Paul Johnson  wrote:
> 
> On Wed, Nov 28, 2018 at 7:46 PM Alan McConchie  > wrote:
> I want to take your feedback with the weight and respect it deserves. I see 
> you voted against "boundary=aboriginal_lands" on the wiki because you prefer 
> "boundary=administrative". Can you clarify more about your proposed 
> alternative?
>  
> In this thread I see you're a fan of admin_level=*, but what admin_level do 
> you propose? The problem I see with that tag is that it follows a strict 
> hierarchy, which reservations don't always follow. It's the hierarchical 
> nature of boundary=administrative that I get hung up on, which is why I like 
> that boundary=aboriginal_lands can exist parallel to that hierarchy.
> 
> For example, if we used boundary=administrative + admin_level=3 (as Kevin 
> Kenny suggested in this thread) that seems clearly wrong for the few 
> reservations that cross national boundaries, like Akwesasne.
> 
> I don't know if a consistent administrative level is possible given the 
> context of each particular tribe and it's respective relationship with the US 
> and Canada.  This may need to be determined on a case-by-case situation.  I 
> do think that admin_level=3 is a pretty reasonable in the US because within 
> tribal lands, if at least one party is a tribal citizen of the nation they're 
> in, I'm not aware of one that doesn't automatically moves jurisdiction to 
> tribal or federal courts exclusively, with state and county courts not having 
> jurisdiction.  In some cases, this might apply to any criminal or civil case 
> within the jurisdiction regardless of who is involved.
>  
> I can understand how others might see boundary=aboriginal_lands as a tag that 
> carries less respect. But I don't see it that way.
> 
> Part of it is the strong tendency of folks making renders to fill-shade the 
> tribal territory like it's a park, wildlife preserve or zoo.  Carto used to 
> have a green "IR" hatch that was almost indistinguishable from the same 
> colored "NR" hatch for indian reservations (which was easily half of my 
> annoyance on the subject in 2013).  Treating tribal boundaries as other 
> political boundaries humanizes the situation.
> ___
> 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] antenna use key to replace some of the antenna type

[Sergio Manzi]

Hello, Warin,

a couple of quick, non-exhaustive, notes on antenna use (or is it /usage/?) 
even if I'm still doubtful we should map with such detail:

  * amateur_radio: antenna systems used by *licensed *radio amateurs
  * transponder: I think they are mostly used on *mobile *systems 
(/unmappable.../). Is there any fixed transponder? What used for? Probably just 
very few fixed AIS station. Make it specific, use=AIS (as wifi is specific 
compared to the generic "digital communication")
  * radar: definition is "RAdio Detection And Ranging"
  * radio: make it specific, broadcast_radio
  * gps: hardly noticeable. They normally are the size of small cup or a table 
dish at most...

missing use:

  * navaid: VOR, LORAN (/I//think there are still some LORAN antenna around, 
probably disused, but conspicuous/), etc.
  * trunked_radio (https://en.wikipedia.org/wiki/Trunked_radio_system)
  * WiMax (https://en.wikipedia.org/wiki/WiMAX)

missing key:

  * band=ELF|SLF|VLF|LF|MF|HF|UHF|SHF|EHF|THF ( 
https://en.wikipedia.org/wiki/Radio_spectrum)

please don't:

  * frequency=* as: A) we probably don't know what they are. B) there are 
probably many used.  C) Even if we know it is better not to tell.

please note:

  * Advise that in many countries you could probably get some serious jail for 
tagging this stuff.

Cheers!

Sergio


On 2018-11-29 02:09, Warin wrote:
> Hi,
>
> Following from my previous post on antenna:type ..
>
>
> This is the first of the antenna:* keys that could be used to categorise 
> various 'types' of antennas.
>
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/antenna:use
>
>
> This one is on the use to which the antenna signal is put.
>
>
> It does need input on the values. And anything else of concern naturally.
>
>
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - Voting - boundary=aboriginal_lands

[Sergio Manzi]

+1000!

On 2018-11-29 03:52, Paul Johnson wrote:
> Treating tribal boundaries as other political boundaries humanizes the 
> situation.



smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - Voting - boundary=aboriginal_lands

[Paul Johnson]

On Wed, Nov 28, 2018 at 9:35 PM Alan McConchie 
wrote:

> Ok, I see. So you propose that these areas should not have any additional
> tags that would identify them as special aboriginal areas, and that the
> admin_level should be chosen on a case-by-case basis depending on the
> circumstances of each area and the country that it's in?
>

Yes, though while not perfect, admin_level=3 isn't a bad default.


> And furthermore you don't want these areas to be styled differently from
> any other administrative boundaries? (and if we follow those tagging
> guidelines, no one would be _able_ to style them differently because they
> wouldn't have any special tags?)
>

That's not the goal, just a happy side benefit.  Given that we have cities
straddling county lines (Tulsa is in Osage, Tulsa and Wagoner Counties),
and we have cities straddling state lines (Siloam Springs is in Oklahoma
and Arkansas), and we have cities that straddle countries (Sault Sainte
Marie is in the US and Canada), I think people are comfortable that
subordinate categories straddle higher administrative levels regularly on
this continent.  Plus for all practical purposes, indian boundaries operate
and function just like any other political boundary.


> I expect that would mean we'd continue to have problems with people
> tagging for the renderer, as in Brazil, where people will tag native
> reservations as nature reserves to get them to show up prominently on the
> map. But if we provided an appropriate generic "administrative" boundary
> style for tagging native reservations, it's true that the tagging for the
> renderer would probably decrease, if not completely go away.
>

So provide guidance.  Like we have to do with people escalating highway
priorities unnecessarily.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - Voting - boundary=aboriginal_lands

[Joseph Eisenberg]

Admin_level=3 is incorrect for reservations. in the USA

They do not have administrative authority that is superior to that of the
admin_level 4 States or even counties (level 6) in most areas of
governance, but in some areas they have even more independence.

No numeric admin_level is going to work in any sensible way.

If this were a North American map we could just use admin_level and expect
data users to figure it out, but any system has to work with the use of
different admin levels in other countries.
On Thu, Nov 29, 2018 at 1:00 PM Paul Johnson  wrote:

> On Wed, Nov 28, 2018 at 9:35 PM Alan McConchie 
> wrote:
>
>> Ok, I see. So you propose that these areas should not have any additional
>> tags that would identify them as special aboriginal areas, and that the
>> admin_level should be chosen on a case-by-case basis depending on the
>> circumstances of each area and the country that it's in?
>>
>
> Yes, though while not perfect, admin_level=3 isn't a bad default.
>
>
>> And furthermore you don't want these areas to be styled differently from
>> any other administrative boundaries? (and if we follow those tagging
>> guidelines, no one would be _able_ to style them differently because they
>> wouldn't have any special tags?)
>>
>
> That's not the goal, just a happy side benefit.  Given that we have cities
> straddling county lines (Tulsa is in Osage, Tulsa and Wagoner Counties),
> and we have cities straddling state lines (Siloam Springs is in Oklahoma
> and Arkansas), and we have cities that straddle countries (Sault Sainte
> Marie is in the US and Canada), I think people are comfortable that
> subordinate categories straddle higher administrative levels regularly on
> this continent.  Plus for all practical purposes, indian boundaries operate
> and function just like any other political boundary.
>
>
>> I expect that would mean we'd continue to have problems with people
>> tagging for the renderer, as in Brazil, where people will tag native
>> reservations as nature reserves to get them to show up prominently on the
>> map. But if we provided an appropriate generic "administrative" boundary
>> style for tagging native reservations, it's true that the tagging for the
>> renderer would probably decrease, if not completely go away.
>>
>
> So provide guidance.  Like we have to do with people escalating highway
> priorities unnecessarily.
>
> ___
> 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] Feature Proposal - Voting - boundary=aboriginal_lands

[Paul Johnson]

On Wed, Nov 28, 2018 at 10:09 PM Joseph Eisenberg <
joseph.eisenb...@gmail.com> wrote:

> Admin_level=3 is incorrect for reservations. in the USA
>
> They do not have administrative authority that is superior to that of the
> admin_level 4 States or even counties (level 6) in most areas of
> governance, but in some areas they have even more independence.
>

Check your local treaties on that.  You'll probably be surprised.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - Voting - boundary=aboriginal_lands

[Mark Wagner]

On Wed, 28 Nov 2018 15:21:28 -0600
Paul Johnson  wrote:

> Not to mention in practice, this is something of a misnomer for most
> tribes in the US.  WaPo has an op-ed
> 
> about a pending SCOTUS case on this, that has a nonzero chance of
> redrawing state lines and affecting national autonomy for tribes..

The Supreme Court is pretty good at avoiding rulings with this sort
of broad effect, while still having the desired outcome for the
individuals involved. See, for example, the ruling in Hollingsworth v.
Perry and the refusal to review various related circuit-court decisions,
before a circuit split forced them to take up Obergefell v. Hodges.

-- 
Mark

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

Re: [Tagging] antenna use key to replace some of the antenna type

[Warin]

Thanks Sergio!

I have updated with some more stuff. A fair proportion from your post - 
comments below.

Wifi sucks as a tag .. it is a system not a use. Rats. Need a value for it.

On 29/11/18 14:40, Sergio Manzi wrote:


Hello, Warin,

a couple of quick, non-exhaustive, notes on antenna use (or is it 
/usage/?) even if I'm still doubtful we should map with such detail:


  * amateur_radio: antenna systems used by *licensed *radio amateurs



A mapper will not be able to tell if they are licensed. So I would not 
stipulate it. And this is tagging the use, not who uses it 
(operator=licensed radio amateur?).


  * transponder: I think they are mostly used on *mobile *systems
(/unmappable.../). Is there any fixed transponder? What used for?
Probably just very few fixed AIS station. Make it specific,
use=AIS (as wifi is specific compared to the generic "digital
communication")

There may be some fixed transponders to identify hazards and enable 
checking. Possibly these are known by there systems name rather than 
there use(age). I'll have to check. Arr a OSMwiki example 
https://wiki.openstreetmap.org/wiki/Key:seamark:radar_transponder:category


 * radar: definition is "RAdio Detection And Ranging"


Yes. There is a wikipedia link on it. But I'll change the text.


  * radio: make it specific, broadcast_radio


OK,  broadcast_television too then?


  * gps: hardly noticeable. They normally are the size of small cup or
a table dish at most...

The ones I am thinking of are 300mm diameter and about 2 kg. They have 
choke rings around them.

Some of these are used to provide compensation to the local GPS equipment.
Humm there will be some use to describe the correction .. WASS if I 
recall correctly.


The other very much larger GPS ones to do the control functions .. there 
will be very few of them around.


I think 'we' should include the other 'GPS' systems here too.
Possibly a better description will be GNSS - global navigation satellite 
system.



missing use:

  * navaid: VOR, LORAN (/I//think there are still some LORAN antenna
around, probably disused, but conspicuous/), etc.


Yes . possible.
Don't think LORAN is used any more.
VOR looks to be halved due to GPS use.
I'll include them with a note about reducing numbers due to GPS adoption.


  * trunked_radio (https://en.wikipedia.org/wiki/Trunked_radio_system)
  * WiMax (https://en.wikipedia.org/wiki/WiMAX)


No to the above 2 .. I think those are systems .. not uses?


missing key:

  * band=ELF|SLF|VLF|LF|MF|HF|UHF|SHF|EHF|THF (
https://en.wikipedia.org/wiki/Radio_spectrum)

please don't:

  * frequency=* as: A) we probably don't know what they are. B) there
are probably many used.  C) Even if we know it is better not to tell.

ELF etc are frequency ranges - spectrums .. not uses. We know what 
frequencies broadcast radios and televisions are so those can be mapped. 
The key frequency=* can have a value that is a range.
The spectrum could also be tagged ... using the wavelength rather than 
the band name. Or do you think a tag for the band name is needed? I 
don't think it is.


Some things are 'classified' and most people won't map that information.


please note:

  * Advise that in many countries you could probably get some serious
jail for tagging this stuff.



Yes. Some places are paranoid. Does not stop outside foreigners mapping 
same. Most of them probably don't know the local attitudes.


 *

Cheers!

Sergio


On 2018-11-29 02:09, Warin wrote:

Hi,

Following from my previous post on antenna:type ..


This is the first of the antenna:* keys that could be used to 
categorise various 'types' of antennas.



https://wiki.openstreetmap.org/wiki/Proposed_features/antenna:use


This one is on the use to which the antenna signal is put.


It does need input on the values. And anything else of concern 
naturally.






___
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