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
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:
+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
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
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
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
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: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
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
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
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
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
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
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
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
20 matches
Mail list logo
