Re: [Tagging] Feature Proposal -- RFC -- service=irregular

[Stefan Keller]

Hi

What about track=service? (key track without 's')

:Stefan

Am Mo., 1. Apr. 2019 um 20:35 Uhr schrieb Markus :
>
> Hi Martin,
>
> On Mon, 1 Apr 2019 at 18:21, Martin Koppenhoefer  
> wrote:
> >
> > this should get a different name, many people would call their tram, light 
> > rail or underground service "irregular" (from a subjective point of view: 
> > you wait for a means and it arrives too late). Not sure how to better call 
> > it, maybe "internal" or "operational" use?
>
> Thanks for your advice! I didn't think of that. However, "operational"
> can be understood as any track that is functional, and other service
> tracks are also "internal". What about auxiliary, alternative, reserve
> or diversion?
>
> ___
> 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] Values in namespaces/prefixes/suffixes Considered Harmful - Or: Stop over-namespacing and prefix-fooling

[Stefan Keller]

Hallo Martin

Am So., 31. März 2019 um 22:01 Uhr schrieb Martin Koppenhoefer
:
> what about amenity=school;place_of_worship
> is this desirable tagging?

No, because amenity=school and amenity=place_of_worship are aka
"top-level" keys (= main entities, main concepts) with one to several
sub-keys.

:Stefan

Am So., 31. März 2019 um 22:01 Uhr schrieb Martin Koppenhoefer
:
>
>
>
> sent from a phone
>
> > On 31. Mar 2019, at 18:07, Stefan Keller  wrote:
> >
> > This deteriorates the quality of OSM - and it hurts, given the fact,
> > that there is a proven alternative with semi-colon separated values,
> > which even allows tagging no-values (e.g.
> > service=no_retail,retail,repair,second_hand).
>
>
> what about amenity=school;place_of_worship
> is this desirable tagging?
>
> What does it mean? A mix of a school and a place_of_worship or a place of 
> worship and a school?
>
> amenity=bench;wastebasket
> amenity=wastebasket;recycling
>
>
> 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] Values in namespaces/prefixes/suffixes Considered Harmful - Or: Stop over-namespacing and prefix-fooling

[Stefan Keller]

Hi,

24. März 2019 12:05 bkil wrote:
> What about these (also added to the wiki talk page)?

Thanks for compiling this list of (over-)namespaced tags currently
which contain mainly yes and are mentioned in this wiki and/or
currently in use in OSM. I renamed the wiki subtitle from "What about
these?" to "List of namespaced tags with yes values" [1].

This steadily growing list gives an indication how critical the
situation in OSM is, given the fact and killer-argument, how difficult
it is to maintain (store, index, group) and search over-namespaced and
prefix fooled keys (as I described here [2]).

This deteriorates the quality of OSM - and it hurts, given the fact,
that there is a proven alternative with semi-colon separated values,
which even allows tagging no-values (e.g.
service=no_retail,retail,repair,second_hand).

:Stefan


[1] 
https://wiki.openstreetmap.org/wiki/Talk:Namespace#List_of_namespaced_tags_with_yes-values
[2] 
https://wiki.openstreetmap.org/wiki/Talk:Namespace#Over-namespacing_and_Prefix-fooling

Am So., 24. März 2019 um 12:05 Uhr schrieb bkil :
>
> What about these (also added to the wiki talk page)?
> https://wiki.openstreetmap.org/wiki/Key:currency#Subtags
> https://wiki.openstreetmap.org/wiki/Key:payment#Keys
> https://wiki.openstreetmap.org/wiki/Key:drink#Keys
> https://wiki.openstreetmap.org/wiki/Key:brewery#Usage
> https://wiki.openstreetmap.org/wiki/Key:diet#Tagging
> https://wiki.openstreetmap.org/wiki/Key:fuel
> https://wiki.openstreetmap.org/wiki/Key:socket#Tags
> https://wiki.openstreetmap.org/wiki/Key:authentication#List_of_sub_tags
> https://wiki.openstreetmap.org/wiki/Tag:man_made%3Dmonitoring_station#Required
> https://wiki.openstreetmap.org/wiki/Key:ref#Key_variations
> https://wiki.openstreetmap.org/wiki/Key:recycling#Materials
> https://wiki.openstreetmap.org/wiki/Key:recording
> https://wiki.openstreetmap.org/wiki/Key:monitoring:weather#Instruments
> https://wiki.openstreetmap.org/wiki/Kathmandu_Living_Labs/exposuresurvey#Services_rendered
> https://wiki.openstreetmap.org/wiki/Tag:sport%3Dgaelic_games
> https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dkneipp_water_cure#Tagging
>
> https://wiki.openstreetmap.org/wiki/Key:toll
> https://taginfo.openstreetmap.org//search?q=toll%3A
>
> Although this one had a reasonable purpose of describing performance,
> most values seem to be "yes":
> https://wiki.openstreetmap.org/wiki/Key:generator:output
>
> Some correctly documented ones are misused quiet often:
> https://wiki.openstreetmap.org/wiki/Key:building:use
> https://taginfo.openstreetmap.org/search?q=building%3Ause%3A
> https://wiki.openstreetmap.org/wiki/Key:vending
> https://taginfo.openstreetmap.org/search?q=vending%3A
> https://wiki.openstreetmap.org/wiki/Key:playground
> https://taginfo.openstreetmap.org/search?q=playground%3A
> https://wiki.openstreetmap.org/wiki/Seasonal
> https://taginfo.openstreetmap.org/search?q=seasonal%3A
>
> TagInfo reveals many more combinations for the above documented ones,
> but here exist undocumented ones too:
> https://taginfo.openstreetmap.org/search?q=project%3A
> https://taginfo.openstreetmap.org/search?q=sells%3A
> https://taginfo.openstreetmap.org/search?q=tickets%3A
> https://taginfo.openstreetmap.org/search?q=communication%3A
> https://taginfo.openstreetmap.org/search?q=emergency%3A
> https://taginfo.openstreetmap.org/search?q=shop%3A
> https://taginfo.openstreetmap.org/search?q=medical_service%3A
> https://taginfo.openstreetmap.org/search?q=language%3A
>
> https://taginfo.openstreetmap.org/search?q=education_system%3A
> https://taginfo.openstreetmap.org/search?q=education_level%3A
> https://taginfo.openstreetmap.org/search?q=education_form%3A
> https://wiki.openstreetmap.org/wiki/Proposed_features/Education_2.0
>
> https://taginfo.openstreetmap.org/search?q=health_specialty%3A
> https://taginfo.openstreetmap.org/search?q=counselling_type%3A
> https://taginfo.openstreetmap.org/search?q=medical_system%3A
> https://wiki.openstreetmap.org/wiki/Proposed_features/Healthcare_2.0
> https://taginfo.openstreetmap.org/search?q=provided_for%3A
> https://wiki.openstreetmap.org/wiki/Proposed_features/Healthcare_2.0/Specialties
>
> On Mon, Jan 7, 2019 at 2:24 AM Warin <61sundow...@gmail.com> wrote:
> >
> > On 07/01/19 10:27, Stefan Keller wrote:
> > > Hi,
> > >
> > > After an answer by Rtfm/ti-lo at namespace wiki page [1] (thanks!) I
> > > have to add some thoughts, especially regarding the multiple values!
> > >
> > > Initially I thought it's just about namespaces which I'm calling
> > > "prefix-fooling" or pseudo-boolean-namespaces. "Pseudo" because users
> > > start adding other values to yes/no like yes/no/ma

Re: [Tagging] Facts and opinions

[Stefan Keller]

Hi

> Am Do., 10. Jan. 2019 um 02:33 Uhr schrieb Bryan Housel :
> > On Jan 9, 2019, at 8:23 PM, Stefan Keller  wrote:
...
> > communication. We all need patience with Wikis and it's curation and
> > users - like we e.g. have patience with when we're discussing things
> > about iD presets or iD functionality (like Copy which remained
> > unimplemented since 2013 - hint to Bryan :-))
>
> Stopped reading here and Unsubscribing.

Bryan, I'd like to thank you for your work. But this reaction is not
really constructive. You seem to prefer the github issue tracker of iD
(which you control) - but a github repo is not the only place for
discussions.

> > But namespacing is not the only means we have to group tags: we also
> > have Presets and Wikis documentation!

Under the impression of this discussion I'm considering to propose an
OSMF working group for data curation (especially tagging and presets).

:Stefan

Am Do., 10. Jan. 2019 um 02:33 Uhr schrieb Bryan Housel :
> > On Jan 9, 2019, at 8:23 PM, Stefan Keller  wrote:
> > Hi,
> >
> > As one of the originators of this thread I'd like to second that the
> > Wiki is important. It's not only a documentation tool but also a
> > communication. We all need patience with Wikis and it's curation and
> > users - like we e.g. have patience with when we're discussing things
> > about iD presets or iD functionality (like Copy which remained
> > unimplemented since 2013 - hint to Bryan :-))
>
> Stopped reading here and Unsubscribing.
> You are not funny, and I don’t need the stress that this mailing list brings.
>
> Good luck with tagging & Bye
> ___
> 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] Facts and opinions

[Stefan Keller]

Hi,

As one of the originators of this thread I'd like to second that the
Wiki is important. It's not only a documentation tool but also a
communication. We all need patience with Wikis and it's curation and
users - like we e.g. have patience with when we're discussing things
about iD presets or iD functionality (like Copy which remained
unimplemented since 2013 - hint to Bryan :-))

In addition I'd like to draw your attention to my three points
expressed in my original thread entitled "Values in
namespaces/prefixes/suffixes Considered Harmful - Or: Stop
over-namespacing and prefix-fooling". IMHO we're on a critical
crossroad because of the new-style namespaces (also favored by the
unique multiCombo functionality in iD among others):
1. How to combine concepts?
2. How to group (sub-)tags?
3. How to handle multiple values?
Namespaces are an attempt to all these.

But IMHO for handling groups (2), there's the Wiki (!) - and Presets.
And for handling multiple values (3) I'd still favor semi-colon
separated as long as possible.

As said, the currently growing over-namespacing and prefix-fooling is
detrimental to the OSM schema and turns key/value ad absurdum.
Regarding (2), namespaces are not meant to group values, but to group
attributes/keys! And regarding (3), pseudo-namespaces are not stored
in one bit, in contrary: those long tag tag strings blow up e.g. the
attribute storage in Vector Tiles unnecessarily.

I've quickly analyzed Switzerland and found e.g. following
pseudo-namespaces containing significant amount of Upper-Case keys
(which is a smell of being values smuggled in keys, since keys should
be lower or unsiginificant case): service:* but also currency;*,
payment:* and fuel:*.

Here once again some considerations.

Instead of this "a hodgepodge of different ways of tagging and
potential for 100s of keys" as Simon said:
  motorcycle:tyres=yes
  service:tyres:car=yes
  service:bicycle:tyres=yes
  payment:visa=yes
  payment:notes=yes
  payment:cash:CHF=yes

All of the above could or should be this:
  sells=tyres:motorcycle;tyres:cars;tyres:bicycle
  payment=visa;notes;cash:CHF

And as a last comment: The addr-namespace is a good example of namespacing!
  addr:city=Timbuktu
  addr:housenumber=1
  addr:postcode=111
  addr:street=Main Street

But namespacing is not the only means we have to group tags: we also
have Presets and Wikis documentation!

:Stefan

Am Do., 10. Jan. 2019 um 00:43 Uhr schrieb Warin <61sundow...@gmail.com>:
>
> On 10/01/19 10:13, Tobias Knerr wrote:
> > On 07.01.19 16:12, Bryan Housel wrote:
> >
> >> I encourage everyone to just disregard everything that’s on the wiki and 
> >> go by what taginfo says as far as how the tags are used and what the 
> >> accepted values are.
> > The wiki is an invaluable source for understanding OSM tagging, and I
> > use it all the time during mapping and when coding software that works
> > with OSM data.
> >
> > Taginfo is an awesome resource as well, and I use it almost daily, but
> > it cannot fully replace the wiki. It tells you that foo=bar has been
> > used thousands of times, but it doesn't tell you what that tag means¹.
> > It also doesn't tell you about the conventions for its use (default
> > values, directionality, lots of other essential details). Ultimately,
> > Taginfo isn't documentation – the wiki is.
>
> +1.
>
> Taginfo does not tell me what landuse=clearing is. It only tells me there is 
> some of use of it.
>
> There is no wiki page on it so there is no help there.
>
> The next thing to do is contact the mappers.. tried that .. one response told 
> me to go to another channel - did that, nothing worth while.
>
> Contact a mapper .. no response there either ...
> Best I can do then is use my brain to think about the words and the mapping 
> context to come up with what I think they meant by it.
> My conclusion is - if it is not documented on the wiki .. it does not exist.
>
>
> >
> > Besides documenting current tagging practice, the wiki is also a useful
> > tool for coordinating and spreading new ideas (even though the specifics
> > of the process can be controversial at times). If you're not a software
> > developer or one of a few highly respected community members,
> > discussions on community channels and wiki proposals are pretty much
> > your only good options to make your genius tagging idea known to the
> > world. Without this first step, that idea is unlikely to get enough
> > traction to even show up in Taginfo to a meaningful extent: Using the
> > tag yourself only gets you so far.
>
> The wiki also help differentiate between things that are close in appearance 
> to the casual mapper.
>
> Things like a netball court can be mapped as a basketball court, until you 
> can see the difference and that is on OSM wiki pages.
>
> >
> > For all these reasons, I consider the wiki a key asset to our project.
> > As a result, I spend a lot of time improving it, as do many other
> > community members. It hurts to see that some 

Re: [Tagging] Values in namespaces/prefixes/suffixes Considered Harmful - Or: Stop over-namespacing and prefix-fooling

[Stefan Keller]

Hi,

After an answer by Rtfm/ti-lo at namespace wiki page [1] (thanks!) I
have to add some thoughts, especially regarding the multiple values!

Initially I thought it's just about namespaces which I'm calling
"prefix-fooling" or pseudo-boolean-namespaces. "Pseudo" because users
start adding other values to yes/no like yes/no/maybe.

My main concern with prefix-fooling or pseudo-boolean-namespaces is
not against namespaces in principle. But this "new-style" tagging has
a strong tendency to defragment OSM and to loose a sense of
reusability. I've listed several problems above. See e.g. "Shop
subtags proposal" [2] as a negative example well because it's key
fragmentation in the form
":=yes/no". Looking at the example
in [2]:

Now I realize, that there are three fundamental questions behind this
"new-style" tagging:

First it's about how to describe objects which contain two 'top-level'
tags, like shop=bicycle and shop=motorcycle (see rationale on [2]). We
have had this issue with businesses for long time on how to combine
e.g. restaurant, bar, hotel, bakery etc.. => IMO I'd handle this as
separate POIs as long as possible.

Second, it's about grouping subtags: Namespaces are an attempt to
this. But this is aka redundant to curated presets...

The third and to me most important issue is about handling multiple
values [5]! Multiple values are undoubtedly a data modeling
requirement. They have been handled so far nolens-volens by the
semi-colon value separator [6] - now with a trend to pseudo-boolean
namespaces. Admittedly, processing semi-colon separated fields is
complex and only few SW can process it. I suspect the reason behind is
it's that multiple values are't handled by programming languages out
of the box (databases like Postgres support that not only as data
types but also in queries).

Just recently the iD Editor maintainer added more multiCombo functions
(like [3]) and presets key (like "service:vehicle" [4]). Both is OK
per se, but the latter preset was undocumented on the Wiki, and
obviously the iD Editor maintainer prefers namespaces over semicolons
for handling multiple values - and both issues seem to be completely
undiscussed!

=> So I urgently propose to discuss and sort of out this multiple
values, respectively "semi-colon vs. pseudo-boolean-namespaces" issue!

:Stefan

P.S. I'm now tending to accept new-style boolean-namespaces - but only
under certain conditions. These conditions start with the usual ones
(see the proposal process) complemented perhaps by the following:
* Is it just about grouping? If yes, obstain from namespaces and look
at presets and document it rather in the wiki.
* Can the proposed key be re-used with/by other objects? If yes,
obstain from (over-specific) namespaces and try to choose a more
common or generic and simple key-value tag.
* Is the proposed key namespace in Mixed Case? If yes, this is a
strong smell indicating that it's a value. So choose a more common or
generic and simple key should.
* (See also the six "consequences of prefix-fooling" in my mail above).

[1] 
https://wiki.openstreetmap.org/wiki/Talk:Namespace#Over-namespacing_and_Prefix-fooling
[2] https://wiki.openstreetmap.org/wiki/Proposed_features/shop_subtags
[3] https://github.com/openstreetmap/iD/issues/5291
[4] https://wiki.openstreetmap.org/wiki/Key:service:vehicle
[5] https://wiki.openstreetmap.org/wiki/Multiple_values
[6] https://wiki.openstreetmap.org/wiki/Semi-colon_value_separator


Am Sa., 5. Jan. 2019 um 16:42 Uhr schrieb Markus :
>
> On Thu, 27 Dec 2018 at 02:05, Stefan Keller  wrote:
> >
> > It's really turning processing of key-values (or key-value pairs KVP,
> > entity-attribute-values EAV, dictionnaries, associative arrays, map
> > collections, Hash stores/hstores) ad absurdum. In addition to the
> > troubles of over-namespacing mentioned above there are following
> > consequences of prefix-fooling - among others (sticking at the example
> > "service:bicycle:retail=yes;service:bicycle:repair=yes;"):
> >
> > * Existing code to validate and cleanup values is in vain: One can't
> > check with usual functions if a value is in range
> > "retail,repair,second_hand".
> > * Existing code to match is in vain too: Prefix-fooled keys pretend to
> > have mixed cases (which they should'nt).
> > * Worse, users still extend "yes/no" values to arbitrary values (which
> > again makes processing unnecessarily complicated).
> > * Even worse, users are encouraged to invent new sparsely used keys
> > (which we can't prevent, but it's less harmful in the values).
> > * Source code is flooded by boolean expressions (which would else be a
> > single function) and need to be predefined in the code (instead of
> &

[Tagging] Values in namespaces/prefixes/suffixes Considered Harmful - Or: Stop over-namespacing and prefix-fooling

[Stefan Keller]

>
> On our local list, this argument usually comes up in the other way around: I 
> usually want to endorse a way to use as much semicolons as possible to ease 
> the work of mappers, while everyone else lists counter arguments that boolean 
> alternatives are the upcoming norm.
>
> The socket key grew up from power_supply, check how they use that in taginfo. 
> Consider the following example:
> socket:cee_17_blue=2
> socket:cee_7_3=yes
>
> It indicates that we have 2 sockets of the first, and they also have some of 
> the second kind, but we don't know how many. Perhaps it came from an import, 
> from memory, or there was simply not enough time to count them all. How else 
> would you tag this?
>
> Getting back to the proposal at hand, how would you map this place?
>
> top_up:phone:Vodafone=yes
> top_up:phone:Telekom=yes
> top_up:phone:Telenor=yes
> top_up:phone:Blue_mobile=no
> top_up:transport=yes
>
> Which one would cut it instead in your opinion?
> top_up:phone=Vodafone;Telekom;Telenor
> top_up:transport=yes
>
> Or this one:
> top_up=phone:Vodafone;phone:Telekom;phone:Telenor;transport
>
> Or try to translate this example:
> top_up:phone=yes
> top_up:transport=yes
>
> Would it correspond to this?
> top_up=phone:transport
>
> Given proper presets & UI, a mapper simply ticks some boxes and be done with 
> it - no typing needed. And anyway, I use the contact:* schema extensively and 
> I do not feel that to slow me down - it's just a matter of learning to touch 
> type or using proper autocompletion.
>
> From a performance perspective, if one has a Telenor card and wants to top 
> up, geolocating a place is as simple as looking up top_up:phone:Telenor=yes 
> in the granular case using a DB index/map (key-value based bigdata storage 
> also shines here). If we crammed everything into the same top_up or 
> top_up:phone field, we would need regexp lookups that are much less 
> efficient. Although, if this was the only drawback, we would have the option 
> to build an intermediate shadow database from the master OSM just for the 
> purpose of efficient lookups (basically normalizing to the same form as seen 
> above).
>
> Actually the best solution would be to combine the advantages of both. It 
> would not be really difficult to come up with an editor in which you could 
> enter top_up:phone=Telenor,Vodafone,Telekom and it would automatically expand 
> to the above form on pressing enter (including the missing entries defaulting 
> to *=no!). Namespacing has the added benefit of sorting the keys 
> alphabetically putting them nearby (the same advantage for contact:*=*), 
> although an interface could choose to compress these as they wish.
>
> Full disclosure: up to now, I was happy to use semicolons in cuisine=*, as I 
> don't expect people to do lookups for these and there's sometimes a dozen of 
> them, but this does cause sleepless night. Fortunately, editors support 
> checkboxes for this field in this scheme.
>
> On Wed, Dec 26, 2018 at 6:03 PM Stefan Keller  wrote:
>>
>> Am Mi., 26. Dez. 2018 um 16:47 Uhr schrieb Martin Koppenhoefer
>> :
>> > For practical reason, I would expect a scheme
>> > characteristic_I_need_to_know=yes/no
>> >
>> > much easier to evaluate than one like:
>> > some_services=foo;characteristic_I_need_to_know;bar
>>
>> No it's not easier. The following
>> some_services_foo=yes/no
>> some_services_characteristic_I_need_to_know=yes/no
>> some_services_bar=yes/no
>>
>> is three times more to read and write for humans, as compared to
>> some_services=foo;characteristic_I_need_to_know;bar
>>
>> and - again:
>>
>> The form "detail:value:sub_value(:...)=?"
>> (1.) breaks fundamental(!) assumptions in OSM (assuming tags as a key
>> and value(s)).
>> And (2) it breaks programming principles (requiring a attribute-name
>> having value(s)).
>>
>> So it's obvious why the Wiki and taginfo and you name it can't cope
>> with it. I'm sorry, but it's hard to be more clear and explicit than
>> that.
>>
>> And I hope for OSM that it's not becoming common - even given there
>> are other bad examples like recycling or service:bicycle [1].
>>
>> :Stefan
>>
>> P.S. Note that it's the fact that there are alternatives especially to
>> the boolean yes/no/unkown case and that tagging schemes like "socket"
>> [2] is acceptable since it's still about a value in the key=value
>> pair.
>>
>> [1] https://taginfo.openstreetmap.org/search?q=service%3Abicycle
>> [2] https://wiki.openstreetmap.org/wiki/Key:socket
>&

Re: [Tagging] Feature Proposal - RFC - Top up

[Stefan Keller]

Am Mi., 26. Dez. 2018 um 16:47 Uhr schrieb Martin Koppenhoefer
:
> For practical reason, I would expect a scheme
> characteristic_I_need_to_know=yes/no
>
> much easier to evaluate than one like:
> some_services=foo;characteristic_I_need_to_know;bar

No it's not easier. The following
some_services_foo=yes/no
some_services_characteristic_I_need_to_know=yes/no
some_services_bar=yes/no

is three times more to read and write for humans, as compared to
some_services=foo;characteristic_I_need_to_know;bar

and - again:

The form "detail:value:sub_value(:...)=?"
(1.) breaks fundamental(!) assumptions in OSM (assuming tags as a key
and value(s)).
And (2) it breaks programming principles (requiring a attribute-name
having value(s)).

So it's obvious why the Wiki and taginfo and you name it can't cope
with it. I'm sorry, but it's hard to be more clear and explicit than
that.

And I hope for OSM that it's not becoming common - even given there
are other bad examples like recycling or service:bicycle [1].

:Stefan

P.S. Note that it's the fact that there are alternatives especially to
the boolean yes/no/unkown case and that tagging schemes like "socket"
[2] is acceptable since it's still about a value in the key=value
pair.

[1] https://taginfo.openstreetmap.org/search?q=service%3Abicycle
[2] https://wiki.openstreetmap.org/wiki/Key:socket

Am Mi., 26. Dez. 2018 um 16:47 Uhr schrieb Martin Koppenhoefer
:
>
>
>
> sent from a phone
>
> > On 26. Dec 2018, at 15:08, Stefan Keller  wrote:
> >
> > Tag-proposals in the form
> > :[:]=yes/no should be
> > avoided. It's shifting values to attribute names!
>
>
> it’s not a value, it‘s a property ;-)
> it depends on your interpretation, e.g. motorroad=yes
> oneway=yes
>
> aren’t these values and we should tag them
> road_restrictions=motorroad;oneway?
>
>
> top_up:phone=yes
> means: provides phone top up.
> For practical reason, I would expect a scheme
> characteristic_I_need_to_know=yes/no
>
> much easier to evaluate than one like:
> some_services=foo;characteristic_I_need_to_know;bar
>
>
> 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 - Top up

[Stefan Keller]

Hi,

Am Mi., 26. Dez. 2018 um 10:13 Uhr schrieb Markus :
> I don't see a problem that would prevent using the proposed tags
> top_up:[:]=yes/no for vending machines, ATMs, convenience

Tag-proposals in the form
:[:]=yes/no should be
avoided. It's shifting values to attribute names!

This detracts processing - given we/OSM already have a non-relational
key-value schema. Specifically it makes processing with presets and
any key-value analysis very hard.

And by saying hard I don't mean it's because some programmers may be
lazy. It's because having a value as part of an attribute-name is
really a wrong data structure.

In fact, ":[:] = boolean"
has to be officially considered harmful!

There are so many tagging alternatives - like the usual tag scheme.

:Stefan

[1] 
https://2018.stateofthemap.org/2018/T061-An_excursion_in_to_the_world_of_OSM_tagging_presets/


Am Mi., 26. Dez. 2018 um 10:13 Uhr schrieb Markus :
>
> I don't see a problem that would prevent using the proposed tags
> top_up:[:]=yes/no for vending machines, ATMs, convenience
> stores, kiosks etc. too.
> On Wed, 26 Dec 2018 at 09:59, Warin <61sundow...@gmail.com> wrote:
> >
> > There are some vending machines that offer 'top up' ... how are these to be 
> > tagged? Together with a payment tag too.
> >
> > There are some convenience stores that offer 'top up' services .. how are 
> > these to be tagged?
> >
> >
> > On 26/12/18 19:31, Markus wrote:
> > > Hi Daniele,
> > >
> > >  From the proposal page:
> > >
> > >> It's possible to specify which brand/carrier vouchers are sold with the 
> > >> key brand=*.
> > >>
> > >> A bar that sells Vodafone phone vouchers: amenity=bar + top_up=yes + 
> > >> brand=vodafone
> > > The brand=* key specifies the brand of the main tag, here amenity=bar.
> > > In your example, this would mean that it's a Vodafone bar.
> > >
> > > Furthermore, top_up=yes doesn't say whether you can top up mobile
> > > phones, public transport cards or something else, for example prepaid
> > > credit cards.
> > >
> > > Therefore i would suggest someting like:
> > >
> > > top_up:mobile_phone=yes/no
> > > top_up:mobile_phone:vodafone=yes/no
> > > top_up:mobile_phone:lycamobile=yes/no
> > >
> > > top_up:public_transport=yes/no
> > > top_up:public_transport:oyster=yes/no
> > > top_up:public_transport:opal=yes/no
> > >
> > > top_up:credit_card=yes/no
> > > top_up:credit_card:ok=yes/no
> > >
> > > Regards
> > > Markus
> > >
> > > On Wed, 26 Dec 2018 at 02:45, Daniele Santini  wrote:
> > >> Link of the proposal: 
> > >> https://wiki.openstreetmap.org/wiki/Proposed_features/Top_up
> > >> Hi, I propose to introduce the top_up=* key to specify whether a 
> > >> shop/amenity sells top-ups (mobile phone credit recharge vouchers,  
> > >> over-the-air credit top up and/or public transport credit recharge 
> > >> vouchers).
> > >> Kind regards
> > >> --
> > >> Daniele Santini
> > >> http://www.dsantini.it
> > >> ___
> > >> 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

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

Re: [Tagging] Dog-friendly cafes

[Stefan Keller]

> That's probably to be discussed over at tagging mailing list.
Sorry, forget this last sentence.

Given that there's like wheelchair=yes and kids_area=yes [1] one could
introduce s'thing like animal friendly properties to amenities (bar,
restaurant, hotel, ...).
But IMHO it should be declared as such at the location and/or the webpage.
No idea yet about the key/values except that it should include also
other animaly besides dogs :-).

:Stefan

[1] http://wiki.openstreetmap.org/wiki/Key:kids_area


2017-10-29 22:08 GMT+01:00 Stefan Keller <sfkel...@gmail.com>:
> Hi,
>
> There are similar keys like "wheelchair" and allowed vehicles in
> streets (http://wiki.openstreetmap.org/wiki/Key:access ).
> If there's enough objectivity in the tag definition I'd support that.
> That's probably to be discussed over at tagging mailing list.
>
> :Stefan
>
>
> 2017-10-29 21:56 GMT+01:00 Philip Barnes <p...@trigpoint.me.uk>:
>> On Sun, 2017-10-29 at 21:29 +0100, Tom Pfeifer wrote:
>>> On 29.10.2017 16:44, Andrew Hain wrote:
>>> > How should an establishment that bills itself as “the dog friendly
>>> > cafe” be tagged?
>>>
>>> dog=* is used 8615 times, of which 1875 are dog=yes.
>>> 5498 uses are on highways, 854 on amenities and 1114 together with
>>> opening_hours
>>>
>>> https://taginfo.openstreetmap.org/keys/dog#values
>>>
>>> Though without its own page, this would be my first recommendation.
>>> See also https://wiki.openstreetmap.org/wiki/Animals
>>>
>> Its a bit more than simply allowed, although I do think dog friendly is
>> a bit subjective in the same way motorcycle friendly was.
>>
>> Maybe you can tag the features that make it dog friendly, such a jar of
>> biscuits, water bowls provided for example.
>>
>>
>> Cafes are not somewhere you would normally classify as dog friendly,
>> non-assistance dogs are not allowed where food is being served, but dog
>> friendly pubs are fairly common.
>>
>> Phil (trigpoint)
>>
>> ___
>> 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] Dog-friendly cafes

[Stefan Keller]

Hi,

There are similar keys like "wheelchair" and allowed vehicles in
streets (http://wiki.openstreetmap.org/wiki/Key:access ).
If there's enough objectivity in the tag definition I'd support that.
That's probably to be discussed over at tagging mailing list.

:Stefan


2017-10-29 21:56 GMT+01:00 Philip Barnes :
> On Sun, 2017-10-29 at 21:29 +0100, Tom Pfeifer wrote:
>> On 29.10.2017 16:44, Andrew Hain wrote:
>> > How should an establishment that bills itself as “the dog friendly
>> > cafe” be tagged?
>>
>> dog=* is used 8615 times, of which 1875 are dog=yes.
>> 5498 uses are on highways, 854 on amenities and 1114 together with
>> opening_hours
>>
>> https://taginfo.openstreetmap.org/keys/dog#values
>>
>> Though without its own page, this would be my first recommendation.
>> See also https://wiki.openstreetmap.org/wiki/Animals
>>
> Its a bit more than simply allowed, although I do think dog friendly is
> a bit subjective in the same way motorcycle friendly was.
>
> Maybe you can tag the features that make it dog friendly, such a jar of
> biscuits, water bowls provided for example.
>
>
> Cafes are not somewhere you would normally classify as dog friendly,
> non-assistance dogs are not allowed where food is being served, but dog
> friendly pubs are fairly common.
>
> Phil (trigpoint)
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

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