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 <sfkel...@gmail.com> wrote: > Am Mi., 26. Dez. 2018 um 16:47 Uhr schrieb Martin Koppenhoefer > <dieterdre...@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 > <dieterdre...@gmail.com>: > > > > > > > > sent from a phone > > > > > On 26. Dec 2018, at 15:08, Stefan Keller <sfkel...@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@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