> We don't want "name:Main Street=yes". You are mixing everything in key, this is not what I suggest.
fullsemantickey=fullsemangicvalue shouldn't be moved to fullsemantickey:fullsemangicvalue=yes This makes to sense, now you have to parse key instead of value... I only talk about separating key=*part-of-value-withown-meaining1;* *part-of-value-withown-meaining2;part-of-value-withown-meaining3;* *part-of-value-withown-meaining4* into separate keys key:semanticsubkey1=yes key:semanticsubkey2=yes key:semanticsubkey3=yes key:semanticsubkey4=yes and not key:value=yes — this is horrible and impossible to query similar to multivalued keys key=parsemevalue1;parsemevalue2;parsemevalue3 — this is also impossible to query (realistically, not with regexes) But it also wrong if you remove all flexibility of multiple keys under really-log-unusable-value simply because "we have relations for that realson". Relations are fine, but keys are easier to understand for newbies and query. Instead of regexes you have to learn about querying only for relations, querying only for members with specific roles. This is donable, but this takes time. This is imporlant. *Roles are not accessible by our documentation or tools*. We cannot use this in presets or localize strings for it. There no difference in documentation for building=yes if it is with role 'inner' or 'address'. Users should decide when to really use ';'. But we should discourage them from using it everywhere. It was proposal multiple times by many users already: http://wiki.openstreetmap.org/w/index.php?title=Key:abandoned&diff=next&oldid=878767 http://wiki.openstreetmap.org/w/index.php?title=Key:disused&diff=next&oldid=862845 http://wiki.openstreetmap.org/w/index.php?title=Semi-colon_value_separator&diff=prev&oldid=1113856 https://wiki.openstreetmap.org/w/index.php?title=Key:is_in&diff=prev&oldid=67210#Problems_of_accuracy Again, see millionshighways with only 1 value http://taginfo.openstreetmap.org/keys/highway#values Many name tags with only 1 value http://taginfo.openstreetmap.org/search?q=name Actually there very-very few examples where this can make sense: ref=3;4 — reference roads with same meaning. There way more reference systems than you may think http://wiki.openstreetmap.org/w/index.php?title=Key:ref&oldid=1129065 opening_hours — this is very specific key you have to process/parse its value each time, you can query "opening_hours"="24/7", but this tag is more complex than "simple tag to tag 24/7 feature" lanes — used to indicate lanes, with specific order, left-to-right http://taginfo.openstreetmap.org/search?q=lanes Can somebody continue this list of exceptions? 2015-01-21 15:23 GMT+03:00 Frederik Ramm <frede...@remote.org>: > Hi, > > On 01/21/2015 12:07 PM, Никита wrote: > > *route_ref:De_Lijn:8=yes* > > *route_ref:De_Lijn:9=yes* > > *route_ref:De_Lijn:284=yes* > > > I want to see bolded keys in database directly > > No. Relations have been invented specifically to avoid this. > > Conceputally, the "value" space should not overflow into the "key" > space. While we allow arbitrary keys, we still want them to be keys, not > a mixture of keys and values. We don't want "name:Main Street=yes". > > No matter what one thinks about semicolon lists, the above is clearly > worse. > > Bye > Frederik > > -- > Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" > > _______________________________________________ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging >
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
