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

[Martin Koppenhoefer]

sent from a phone

> On 28. Nov 2018, at 02:54, Doug Hembry  wrote:
> 
> if this is "policy", does it mean that 
> boundary=protected_area, and protect_class=* tags are doomed in OSM? 
> Have we found the covert reason why carto still doesn't render it, 
> despite the fact that it could be rendered (at least initially) exactly 
> like boundary=national_park?


to make sense of boundary=protected area, one has to look at the protect_class, 
which wasn’t possible in carto until recently (hstore). It is not an option to 
render all protected areas as nature protected areas, that would be highly 
misleading in many occasions.

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

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

[Martin Koppenhoefer]

sent from a phone

> On 28. Nov 2018, at 02:54, Doug Hembry  wrote:
> 
> I'm also wondering (an even broader question) at the justification for 
> making a decision like this (the approval of boundary=aboriginal_lands) 
> on the basis of 20 or so votes (so far, hopefully more to come)  mostly 
> from involved and passionate supporters of the proposal out of the 
> hundreds of thousands in the OSM community.


The number of people voting is usually in this range, while it would be better 
to have a wider participation in the tag development process, it simply isn’t 
the case. Most people apparently (and many declaredly) just want to map based 
on established tags and not dedicate time to advance the scheme. I still am 
confident that the process is somehow working, if a vote looks like  it could 
become skewed (due to general low participation numbers it doesn’t look very 
hard to distort a result), I guess more people could be mobilized to get a 
broader picture. Also questions that touch a broad field usually get more 
participation than “specialist” areas.



> Where are the OSM'ers who 
> originally created the boundary=protected_area proposal and got it 
> approved. Have they voted?


you can see it by looking at the usernames. Well, if you can find the proposal 
(maybe there wasn’t any, that was normal in 2009). Looking at the history, the 
process seems dominated by one user, this is apparently the first page about 
the tag: https://wiki.openstreetmap.org/wiki/Special:MobileDiff/363402

By the time, I thought it would be a good scheme because it distinguished the 
hierarchy (level: national, regional etc.) and the protection scope (natural, 
cultural, etc.), and had also a structured tag (pr.title) for the actual class 
name —- and numeric values were still quite common in tagging anyway (sac 
scale, tracktype, admin_level), although those numbers are actually easier to 
understand because they express a hierarchy, unlike the protect classes which 
are just codes.

Compared to the 2 tags that already were established in 2009,
leisure=nature_reserve and boundary=national_park,
it seemed more versatile and universally applicable.

I still believe it is desirable to have a scheme which offers ways to precisely 
define the kind of protected area, just that numbered classes for the scope 
were a bad idea. Especially because it is the essence of the thing to know what 
is protected, not just a detail. A good scheme should allow for both: adding 
rough information and refine it with details. At least for a basic 
representation you should not have to resort to lookup tables or presets.
I am also not sure any more whether we should put all kinds of protected areas 
in the same bucket, maybe there could already be a first class distinction 
between natural protection, resource protection and social protection.

e.g. “water_protection_area” rather than a handful of protected tags with 
obscure protection classes. 
On the other hand, I would not create first level classes to distinguish 
between a national park and a regional park.

Generally for a scheme to gain ground it is helpful to be structured in a way 
that makes it possible for standard osm2pgsql style based DBs to make sense of 
the tagging, although this aspect is becoming less important with more people 
using hstore or similar structures (unlimited keys).

Cheers, Martin 


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

On 2018-11-29 07:27, Warin wrote:
>>
>>   * 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?). 

Then retract the proposal for use=amateur_radio (/and citizens_band_radio/) as 
radio amateurs are defined by their licensed status and you can't tell a thing 
about who is using an antenna by simply looking at it. And radio amateurs uses 
all kind of antenna through the full spectrum, ELF to TLF, and they often are 
at the forefront of antenna design. I also suspect you tend to confuse CB with 
the activity of "chatting on the radio" (/"//rag chewing" in hams parlance/). 
CB is a band (Citizens Band, around 27MHz), not an use, unless you 
(/incorrectly/) define it as "/same things hams do, but without a licens/e". 
Also hams make different _uses_ of their status/capabilities through their 
apparatus and antenna. Either you have of knowledge of the fact or you can't 
tell a CB antenna from an ham radio antenna on the 10m band.


>   * radio: make it specific, broadcast_radio
>
> OK,  broadcast_television too then? 

At the end of the day I'd rather define them as /tv_broadcasting/ and 
/radio_broadcasting/. Even better /broadcasting/, tout-court, for both usages



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

There are *many* very conspicuous (ex) LORAN-C antennas around the world: look 
at satellite images starting from the list at 
https://en.wikipedia.org/wiki/Loran-C#List_of_LORAN-C_transmitters.

There is still a lot of  VOR together with other navaids such as ILS, TLS, MLS 
and probably many others I don't know of. Anyway VORs are not dying at all: 
have a look at https://www.openaip.net/navaids and 
https://www.faa.gov/about/office_org/headquarters_offices/ato/service_units/techops/navservices/transition_programs/vormon/


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

Then why yes to WiFi? WiFi is a standard (/actually a set of standards/), same 
as WiMax, defining systems meant for (/broadly/) the very same usage cases, 
only at different scales...

>   * 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 term is WAAS (Wide Area Augmentation System) and is a *system* (/using 
several type of antennas, also satellite uplink dishes/, /not only the 
receiving reference antenna/) for augmenting the accuracy of the GPS system for 
air navigation purposes (/I think the DGPS system has the same purpose but is 
oriented to marine navigation.../).

Yes, GNSS (/last "s" is for "system" here too.../) is a broader and more 
correct term compared to gps and "satnav" can do too, I guess...


Yes, sorry, antenna:band and antenna:frequency doesn't have anything to do with 
the current antenna:use proposal, I was just freewheeling...

I think you forgot the  "satellite communication" use, which itself can be 
divided in some very different use (tracking, control, data up/down-link, etc..)


---*
*

*At the end of the day... I think this proposal has same serious issues: the 
use of an antenna system can be decided only if you have internal knowledge of 
what it is actually used for, not just looking at the antenna.  Also, either we 
define a very broad range of usage cases or a very fine list of them (in the 
hundreds, I guess...). *I'll probably vote against...*
*

On a broader account, do we really want OSM to become a "database of the 
world", with all its details/, /even fine technical details which IMHO are more 
fit to the blueprints of an infrastructure?

Cheers,

Sergio
**




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

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

[Michael Brandtner]

If I pay per SMS, then I don't pay per app. It doesn't make sense to have both 
in the same key. I do like bkil's suggestions but do think that the tags should 
be as specific as possible, even if that means to have multiple keys with the 
same value.
So for 
example:payment:sms=yespayment:AppName1=yespayment:AppName2y=yesref:sms=12345contact:sms=0127ref:AppName1=12345ref:AppName2=12345
This leads me to another interesting question: Should these be added to 
amenity=parking or to vending=parking_tickets? In my opinion it makes more 
sense to add them to the parking lot itself because I don't need the ticket 
machine if I use pay by phone. But the wiki only suggests payment=* keys for 
vending=parking_tickets, not for amenity=parking. 

Sergio Manzi  schrieb am 21:15 Mittwoch, 28.November 2018:
 

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

Don't you see it *possible* that sms payment can be made through different 
clearinghouses/operators? Really?

Cheers!


On 2018-11-29 14:13, Michael Brandtner wrote:
> If I pay per SMS, then I don't pay per app. It doesn't make sense to have 
> both in the same key. I do like bkil's suggestions but do think that the tags 
> should be as specific as possible, even if that means to have multiple keys 
> with the same value.
>
> So for example:
> payment:sms=yes
> payment:AppName1=yes
> payment:AppName2y=yes
> ref:sms=12345
> contact:sms=0127
> ref:AppName1=12345
> ref:AppName2=12345
>
> This leads me to another interesting question: Should these be added to 
> amenity=parking or to vending=parking_tickets? 
> In my opinion it makes more sense to add them to the parking lot itself 
> because I don't need the ticket machine if I use pay by phone. But the wiki 
> only suggests payment=* keys for vending=parking_tickets, not for 
> amenity=parking.
>
>
> Sergio Manzi  schrieb am 21:15 Mittwoch, 28.November 2018:
>
>
> 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
> ___
> 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 Signatu

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

[Martin Koppenhoefer]

sent from a phone

> On 28. Nov 2018, at 21:07, bkil  wrote:
> 
> I don't recommend using payment:pay_by_phone=* or
> payment:contactless=* due to the sheer number of incompatible
> different payment solutions (see wiki).


I agree, these are bad because there are too many alternative systems that 
would all fall into these categories, and the future will likely bring more. 

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

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

[Martin Koppenhoefer]

sent from a phone

> On 28. Nov 2018, at 21:14, Sergio Manzi  wrote:
> 
> payment:sms=yes
> payment:sms:WhateverPayApp=yes
> 

+1


> payment:sms:WhateverPayApp:contact=
> 


Does not look very sustainable, are we going to mass retag all of these if the 
number changes? I agree it might be useful to have this information, but it 
shouldn’t need to be tagged on every instance where you can pay (unless the 
number is individual and not universal), e.g. it could be entered in the wiki.


> payment:sms:WhateverPayApp:ref:payment=
> 


two times ‘payment’? Maybe payment:sms:ExampleApp:payment_ref=

or ...code_to_send=*

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

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

[Martin Koppenhoefer]

sent from a phone

On 29. Nov 2018, at 17:11, Martin Koppenhoefer  wrote:

>> payment:sms:WhateverPayApp:contact=
>> 
> 
> 
> Does not look very sustainable, are we going to mass retag all of these if 
> the number changes? I agree it might be useful to have this information, but 
> it shouldn’t need to be tagged on every instance where you can pay (unless 
> the number is individual and not universal), e.g. it could be entered in the 
> wiki.


if it must be a tag, it should follow the established conventions, e.g. phone 
rather than contact. Apps usually do not expose or require a phone number 




> 
> 
>> payment:sms:WhateverPayApp:ref:payment=
>> 
> 


maybe just “ref”, unless it is different? We are using ref for example for bus 
stops where you can use this code to dynamically query an api for bus arrival 
times. As long as it is just one reference number, there’s no need to declare 5 
levels of nested structures ;-)

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

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

[Sergio Manzi]

Hi Martin!

On 2018-11-29 17:11, Martin Koppenhoefer wrote:

> payment:sms:WhateverPayApp:contact=
>
>
> Does not look very sustainable, are we going to mass retag all of these if 
> the number changes? I agree it might be useful to have this information, but 
> it shouldn’t need to be tagged on every instance where you can pay (unless 
> the number is individual and not universal), e.g. it could be entered in the 
> wiki.
>
>
I'm not familiar with the technology. If the phone number to use is always the 
same for a given app/service, I totally agree with you.


On 2018-11-29 17:11, Martin Koppenhoefer wrote:
>>
>> payment:sms:WhateverPayApp:ref:payment=
>>
>
>
> two times ‘payment’? Maybe payment:sms:ExampleApp:payment_ref=
>
> or ...code_to_send=*

Right! Too many payments! :-) To spare some bytes it could be: 
payment:sms:ExampleApp:code=.  What do you think?

Cheers!

Sergio



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

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

[Sergio Manzi]

On 2018-11-29 17:17, Martin Koppenhoefer wrote:
> maybe just “ref”, unless it is different? We are using ref for example for 
> bus stops where you can use this code to dynamically query an api for bus 
> arrival times. As long as it is just one reference number, there’s no need to 
> declare 5 levels of nested structures ;-)
>
Different services/clearinghouses could require different codes... or not? :-/




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

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

[Sergio Manzi]

I mean, today maybe you have just one service/clearinghouse and a simple ref: 
could do, but then tomorrow a new service/clearinghouse requiring a different 
code is added.

Then you must "namespace" the second code, but the first...  stay un-namespaced?

Languages must be extensible...

Sergio


On 2018-11-29 17:20, Sergio Manzi wrote:
> On 2018-11-29 17:17, Martin Koppenhoefer wrote:
>> maybe just “ref”, unless it is different? We are using ref for example for 
>> bus stops where you can use this code to dynamically query an api for bus 
>> arrival times. As long as it is just one reference number, there’s no need 
>> to declare 5 levels of nested structures ;-)
>>
> Different services/clearinghouses could require different codes... or not? :-/
>
>



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

[Daniel Koć]

W dniu 29.11.2018 o 11:38, Martin Koppenhoefer pisze:
> I am also not sure any more whether we should put all kinds of
> protected areas in the same bucket, maybe there could already be a
> first class distinction between natural protection, resource
> protection and social protection.


I was trying to use this in my first approach to protected areas, but I
have found that only protection_level numbers were standardized. Others
are (mostly) human readable mess, for example:

https://taginfo.openstreetmap.org/keys/?key=protection_title#values

I would love to just render "nature-protected-area" (because this is the
abstraction level I need), but in practice I had to define a list:

tags->'protect_class' IN
('1','1a','1b','2','3','4','5','6','7','97','98','99')

It's perfectly usable, but just not elegant and not human readable.


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

[Martin Koppenhoefer]

sent from a phone

> On 29. Nov 2018, at 17:20, Sergio Manzi  wrote:
> 
> Different services/clearinghouses could require different codes... or not? :-/


it may depend on the service, if needed you can add deeply structured tags of 
course, but sometimes there will be just one number which is used across 
payment systems (sms, web, etc), e.g. for parking tickets, so ref seems 
sufficient then


Cheers, Martin 


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

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

[Martin Koppenhoefer]

sent from a phone

> On 29. Nov 2018, at 17:25, Sergio Manzi  wrote:
> 
> Languages must be extensible...


there’s always a way to extend ;-)
Shorter tags are more convenient for mapping and make it more likely someone 
will add it. Language, like our tags, usually has context, a ref on a road will 
likely be presented differently to a map user than a ref on a parking ticket 
machine 

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

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

[Graeme Fitzpatrick]

On Fri, 30 Nov 2018 at 02:19, Sergio Manzi  wrote:

> Right! Too many payments! :-) To spare some bytes it could be: payment:
> sms:ExampleApp:code=.  What do you think?
>
I would think that it shouldn't be up to OSM to list all the ways someone
can pay for parking, down to which app to use or phone number to call / SMS.

OSM should say that "this" area is paid parking & leave it at that - once
the driver parks their car, they walk over to the payment terminal & all
the necessary info is listed there, & updated as needed by the car park
operator - their problem, not our's!

Thanks

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

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

[Sergio Manzi]

+1 You're my hero!

To clarify: my contribution was about making right (/according to my point of 
view, of course/!) something that I thought had issues, but in a general way 
I'm totally with you and I'm finding a little bit crazy the level of details 
that someone want to use in the description of OSM features, some of which, I 
think, should have very little to do with OSM (/I'm thinking of the 
//meticoulous description/mapping of //infrastructures of less than general 
interest. As I said elswere: should we map railroad ties too?/).

Thanks!

Sergio


On 2018-11-29 21:29, Graeme Fitzpatrick wrote:
>
>
> On Fri, 30 Nov 2018 at 02:19, Sergio Manzi mailto:s...@smz.it>> 
> wrote:
>
> Right! Too many payments! :-) To spare some bytes it could be: 
> payment:sms:ExampleApp:code=.  What do you think?
>
> I would think that it shouldn't be up to OSM to list all the ways someone can 
> pay for parking, down to which app to use or phone number to call / SMS.
>
> OSM should say that "this" area is paid parking & leave it at that - once the 
> driver parks their car, they walk over to the payment terminal & all the 
> necessary info is listed there, & updated as needed by the car park operator 
> - their problem, not our's!
>
> Thanks
>
> Graeme
>  
>
> ___
> 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

[Doug Hembry]

On 29. Nov 2018, at 10:40, Daniel Koć  wrote:
I was trying to use this in my first approach to protected areas, but I have 
found that only protection_level numbers were standardized. Others are (mostly) 
human readable mess, for example: 
https://taginfo.openstreetmap.org/keys/?key=protection_title#values
I would love to just render "nature-protected-area" (because this is the 
abstraction level I need), but in practice I had to define a list: 
tags->'protect_class' IN ('1','1a','1b','2','3','4','5','6','7','97','98','99')
It's perfectly usable, but just not elegant and not human readable.

Would  you also render boundary=protected_area if protect_class=* is absent 
entirely? I think this would be a good idea.
It's highly desirable that someone can do a rough tagging of a protected  area 
before they know much about it (or don't care) and later (maybe someone else) 
can come along and add the protect_class=* tag. (Though maybe protect_title 
should be required). If this means the boundary rendering defaults to a green 
border, that sounds OK IMO.
(If it's too late, and the code is written and tested ignore this note..:-))
- doug
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Feature Proposal - Voting - emergency=fire_alarm_box

[Stefano Maffulli]

Hello folks,

the fire alarm box tag has been in RFC status for a while and all the
concerns raised have been addressed.

Here is the proposal
https://wiki.openstreetmap.org/wiki/Proposed_features/fire_alarm_box

Please leave your votes and comments.

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

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

[Doug Hembry]

Hi Martin,
That was an interesting analysis. I enjoyed reading it, and found I pretty much 
agree with your points. A few embedded comments below:

On 29. Nov 2018, at 10:40, Martin Koppenhoefer wrote:
By the time, I thought it would be a good scheme because it 
distinguished the hierarchy (level: national, regional etc.) and the protection 
scope (natural, cultural, etc.), and had also a structured tag (pr.title) for 
the actual class name —- and numeric values were still quite common in tagging 
anyway (sac scale, tracktype, admin_level), although those numbers are actually 
easier to understand because they express a hierarchy, unlike the protect 
classes which are just codes.
>> +1, and I still think so, on the whole. If you look at the ICUN website 
>> (referenced from the boundary=protected_area wiki page), there is an intent 
>> to define a sort of a hierarchy of protection levels from wilderness down to 
>> resource extraction (for p_classes 1 through 6). I agree it's rather 
>> obscure, and doesn't come through at all clearly on the wiki page. Also the 
>> wiki look-up tables (at least for the US) need work.

 Compared to the 2 tags that already were established in 2009, 
leisure=nature_reserve and boundary=national_park, it seemed more versatile and 
universally applicable.
>> +1 This is the main reason for my interest in boundary=protected_area. We 
>> need something. There's a lot of blatant misuse of those two old tags - 
>> people use them just to get boundaries to render.

 I still believe it is desirable to have a scheme which offers ways to 
precisely define the kind of protected area, just that numbered classes for the 
scope were a bad idea. Especially because it is the essence of the thing to 
know what is protected, not just a detail. A good scheme should allow for both: 
adding rough information and refine it with details. At least for a basic 
representation you should not have to resort to lookup tables or presets.
>> +1 (mostly). The boundary=protected_area scheme allows rough/detail tagging 
>> to some degree, I think. I presume you can specify b=p_area without adding 
>> p_class if you wish (though IMHO p_title ought to always be specified). I'm 
>> not wild about numbers for p_class, but I don't know how else to succinctly 
>> specify purpose and level-of-protection, which I do think is desirable and 
>> is not always obvious from the title. Plus any change at this stage would be 
>> difficult? (see numbers below)

...I am also not sure any more whether we should put all kinds of protected 
areas in the same bucket, maybe there could already be a first class 
distinction between natural protection, resource protection and social 
protection.  e.g. “water_protection_area” rather than a handful of protected 
tags with obscure protection classes.
>> +1 Problem is, there are already around 8000 uses in the "resource area", 
>> and over 4000 in "social" (from counting the corresponding p_classes in 
>> TagInfo), so introducing new top-level tags is going to affect a lot of 
>> existing data. The boundary=aboriginal_lands proposal only replaces 
>> p_class=24 (about 600 uses), but I bet we will now have two ways of mapping 
>> the same thing for a long time.

. On the other hand, I would not create first level classes to distinguish 
between a national park and a regional park.
>> +1

>> My overall take: this is a well established tag set, with around 70k uses of 
>> boundary=p_area, and around 50k uses of p_class and of p_title, so a lot of 
>> people are actually finding it usable, and its going to be difficult to 
>> change it substantially. IMO, I think we should focus on more user-friendly 
>> documentation and possibly editor assistance.

One idea: split the p_class wiki documentation off from boundary=p_area into a 
wiki page of its own. Even consider having separate p_class wiki pages for each 
country, with smaller, better explained look-up tables.

Another idea: The presets in JOSM et al could have the mapper fill in the 
p_title (or select it from a list) and do a software look up of the title in a 
country specific table and display a suggested p_class. If the editor doesn't 
find the title in its table the mapper would have to research the correct 
p_class and enter it manually, but this might be quite unusual. However it 
sounds like a lot of work for the JOSM and other editor teams.

But in any case, I'm optimisticonce we have rendering of the 
boundary=protected_area set I think we'll find we're in pretty good shape.

[BTW, a bit off the topic, but we have a local website called calands.org which 
shows all the protected areas in California (if you look, click on the "Explore 
CPAD Map" button on the opening map). It illustrates a couple of points:
1) We're up to our ears in protected areas around here, and there are 
probably (at a guess) over 50 different titles.  Not sure if this is the same 
in other states/countries. But hen

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

[Daniel Koć]

W dniu 29.11.2018 o 22:48, Doug Hembry pisze:
> Would  you also render boundary=protected_area if protect_class=* is
> absent entirely? I think this would be a good idea.


They are too general conceptually, so I try to stay on the safe side. As
you can see with current topic, even this specific subtype might need
some special rendering.


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



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