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 su
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
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
_
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_titl
+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
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 phon
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 w
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 us
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 tryi
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
O
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 lev
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 ev
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
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
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 tha
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 bu
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
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?
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
>
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 render
20 matches
Mail list logo
