> 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
