[Tagging] Feature Proposal - RFC - Top up

bkil bkil.hu+Aq at gmail.com
Wed Dec 26 19:03:53 UTC 2018


Stefan, I think most of us here do not fully understand your hard
arguments, but if you could please elaborate a bit more or give some more
examples, maybe we could better address your concerns. Anyway, this
question sounds a bit orthogonal to the proposal at hand. Could anyone
please link to a previous discussion with arguments in this topic? I'm
absolutely sure that it comes up annually around here, but I'm newbie here,
so I can't tell from the top of my head.

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 <sfkeller at gmail.com> wrote:

> Am Mi., 26. Dez. 2018 um 16:47 Uhr schrieb Martin Koppenhoefer
> <dieterdreist at gmail.com>:
> > 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
> <dieterdreist at gmail.com>:
> >
> >
> >
> > sent from a phone
> >
> > > On 26. Dec 2018, at 15:08, Stefan Keller <sfkeller at gmail.com> wrote:
> > >
> > > Tag-proposals in the form
> > > <tag_attr_name>:<type_value->[:<subtype_value>]=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 at openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/tagging
>
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20181226/0e775170/attachment-0001.html>


More information about the Tagging mailing list