The 'new' public transport scheme actually has 'binary' keys for bus, tram, train, etc.
When you ask to have it rendered, one of the arguments for not doing so is that those extra fields are not imported in the DB specifically set up for rendering. It's considered too complicated, even though the system is better designed than what we started out with. Just to add to the discussion that binary keys for all possible options are apparently not always the solution either. In any case, it's not impossible to work with ; delimited lists, but it's enough if we try to limit their use. Just don't try to eradicate them, they do have their use. I wouldn't want to have to add: route_ref:318=yes route_ref:616=yes or route_ref:BE:De_Lijn:1=yes route_ref:BE:De_Lijn:2=yes ... instead of this: route_ref:De_Lijn=1;2;3;4;5;6;7;8;9;284;285;310;315;316;317;333;334;335;337;351;352;358;370;371;372;373;374;380;395;520;524;525;537;586;597 Polyglot 2015-01-21 11:08 GMT+01:00 Никита <acr...@gmail.com>: > > traffic_calming = table; choker in Russia? > This is not specific to Russia actually. Not many software will support > tagging: > traffic_calming:table=yes > traffic_calming:chocker=yes > > Is there problem to tag this in database and covert to "traffic_calming = > table; choker" to get support in legacy software or outdated tools? > > We use this pattern for almost anything in OSM that has multiple keys or > values (different meanings actually "table"s "chocker"s): > http://wiki.openstreetmap.org/wiki/Key:disused > http://wiki.openstreetmap.org/wiki/Key:abandoned > http://wiki.openstreetmap.org/wiki/Key:source > > Please see links above, they are in English. Also, fuel: key page was > created at 2010. > > I think we should start using both tagging schemes right now: > cuisine=simplevalueforoldsoftware > > *And actual tags for new software and presets* > cuisine:japanse=yes > cuisine:chinese=yes > > This is absolutely not new. See disused, abandoned. > > Over time we will deprecate simple tags cuisine=X and possibly shop=X. > > > 2015-01-21 12:37 GMT+03:00 Marc Gemis <marc.ge...@gmail.com>: > >> How do you tag traffic_calming = table; choker in Russia ? >> >> I'm willing to adapt my tagging, but how can I do this ? Both forms of >> traffic calming are used at the same place sometimes, a table that is >> smaller than the rest of the road. >> >> Furthermore what about cuisine ? Do you use cuisine:japanse=yes, >> cuisine:chinese=yes ? >> >> If you are using all those subkeys since 2010, why aren't they documented >> in the wiki ? I only joined the project in 2011, but have never seen this >> being documented for all those keys... >> >> regards >> >> m. >> >> On Wed, Jan 21, 2015 at 10:23 AM, Никита <acr...@gmail.com> wrote: >> >>> > Java has regular expressions as well [1], I know they are not for the >>> every day user, but this problem also holds for OR, AND. There are a lot of >>> people that do not understand logical expressions. >>> Furthermore, many word editors allow to search for word boundary >>> (defined on spaces, and other punctuation), so you could search for "coin" >>> without finding "bitcoin". If this is not possible in JOSM, maybe it has to >>> be added. >>> My point is still the same. Java regexes are simpler, yes. They miss >>> perl recursion and other perl specific stuff. God bless java language >>> developers for doing this. But this is irrelevant to my points about wiki >>> documentation or about need to teach *any regex* to josm user or id >>> user. >>> >>> We don't use multiple values for many things: >>> http://wiki.openstreetmap.org/wiki/Names#Key_Variations >>> http://wiki.openstreetmap.org/wiki/Key:highway#Values >>> ... just open taginfo or do postgres query to see actual numbers. >>> >>> I have no idea why one would prefer >>> semantickey=literal1;literal2;literal3 over *key:semanticsubtag=value*. >>> >>> For the latter: >>> - you make simple queries even with overpassQL or josm search >>> - you can make presets in iD or JOSM with translations in native language >>> - you can make wiki page about it >>> - you can send this link page to newbie >>> - you can be sure about meaning of this value >>> >>> Why is there need to guess liretal values instead of semantically >>> tagging using ":" in key. Russian community was doing this since 2010. Do >>> English wiki or users that behind us? Is there real reason to support ';"? >>> I was really surprised when my changes were simply reverted. >>> >>> Actually not that bad: >>> http://wiki.openstreetmap.org/w/index.php?title=Key:fuel&direction=next&oldid=400799 >>> was >>> here since 2010. >>> >>> > Now you're insulting the one person who was supporting you? Please >>> No I didn't. Quote them. >>> >>> PS. Well I'm sorry for my tone if it was looking unacceptable in some >>> messages. >>> >>> 2015-01-21 12:00 GMT+03:00 Dan S <danstowell+...@gmail.com>: >>> >>>> Now you're insulting the one person who was supporting you? Please >>>> STOP this thread everyone. Please. >>>> >>>> 2015-01-21 8:55 GMT+00:00 Никита <acr...@gmail.com>: >>>> >> Just because one can use a regular expression to grep out a certain >>>> >> meaning doesn't mean it's a good thing to do and will always work >>>> > We easily revert these edits in Russia. Quite often user who want to >>>> show >>>> > their regex fu will fail so hard to guess actual properly of the real >>>> world. >>>> > >>>> > We care about data we map. >>>> > We document it instead of guessing by taginfo. >>>> > We use real tags instead of regexes for users. >>>> > >>>> > We like our newbies. We don't want to insist to use f$#$g perl regexes >>>> > simply to map things around them. >>>> > >>>> > I cannot stop you from using regex. But if I find your changsets >>>> erroneous I >>>> > will revert them. >>>> > >>>> >> In fact, nobody forces us to only use yes and no as a value. >>>> > Wrong. It not forces you anything. You can still tag currency:X=fixme. >>>> > >>>> >> The Healthcare 2.0 proposal uses partial, main, yes and no. This can >>>> >> easily applied to a lot of values where it makes sense and it gives >>>> the >>>> >> flexibility to distinguish between equal and distinguished >>>> importance . >>>> > There way more tagging schemes than single Healthcare 2.0. Yes there >>>> > differences, so what? >>>> > >>>> >> Using semicolon-lists for values was always considered a crutch >>>> until a >>>> >> better tagging-scheme comes along. >>>> > You forgot to say "among English speaking users who fail to use JOSM >>>> search >>>> > funtion or overpass or taginfo or wiki documentation". I don't care >>>> about >>>> > them. >>>> > >>>> >> We all know that the only real solution would be a native data type >>>> for >>>> >> arrays in the database but as long as this isn't happening, we have >>>> to work >>>> >> around. >>>> > And obviously you choose the worst way to do this. With complicating >>>> things >>>> > with REGEX. >>>> > >>>> > >>>> > 2015-01-21 11:42 GMT+03:00 Nadjita <tagg...@mark.reidel.info>: >>>> >> >>>> >> On 21.01.2015 09:06, Никита wrote: >>>> >> >>>> >> > If you trying to parse name=school *with any regex *to map it as >>>> >> > amenity=school* *you are wrong. OSM is not for you. >>>> >> > If you trying to parse currency=bitcoin;coin for coin, then stop it >>>> >> > right now. You have no idea how regexes or tags in osm work. >>>> >> >>>> >> While I think, you should really calm down a bit and not sound so >>>> >> aggressive, I have to agree with you. The purpose of structuring >>>> data is >>>> >> not having to use a complicated, but a simple parser. Just because >>>> one >>>> >> can use a regular expression to grep out a certain meaning doesn't >>>> mean >>>> >> it's a good thing to do and will always work. >>>> >> The only downside of currency:X=yes, currency:Y=yes to currency=X;Y >>>> is >>>> >> that it involves more typing. In fact, nobody forces us to only use >>>> yes >>>> >> and no as a value. The Healthcare 2.0 proposal uses partial, main, >>>> yes >>>> >> and no. This can easily applied to a lot of values where it makes >>>> sense >>>> >> and it gives the flexibility to distinguish between equal and >>>> >> distinguished importance . >>>> >> Using semicolon-lists for values was always considered a crutch >>>> until a >>>> >> better tagging-scheme comes along. >>>> >> We all know that the only real solution would be a native data type >>>> for >>>> >> arrays in the database but as long as this isn't happening, we have >>>> to >>>> >> work around. >>>> >> But please let's not drag this down to a personal level and start >>>> >> insulting each other, this isn't going to accomplish anything but >>>> anger. >>>> >> >>>> >> - Nadjita >>>> >> >>>> >> _______________________________________________ >>>> >> 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 >> >> > > _______________________________________________ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > >
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
