> 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, if data is clean and consistent, conversion process should be easy even for legacy renders or routing software. We should work on documentation for more user friendly tools ( http://wiki.openstreetmap.org/wiki/Osmosis/Writing_Plugins)
If you know structure your information, there nothing complex for you. In most situations you say when some old tag should be replaced with newer version. But I do agree conversion software support may be not the ATM or poorly documented. > 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 It is possible to get sting route_ref:De_Lijn=8;9;284 from keys in database *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, for now tag with short key and multuple namespaced tags may duplicate each other. But you will also benefit from this. As I said previously, you can use queries like this: *"route_ref:De_Lijn:284"="yes" and "**route_ref:De_Lijn:10"!=** — this query will capture missing 10 and present 284. You will spend hours for learning regexes for yourself and teaching other users how to use regex. Now, after you realized "10" was missing, you have to enter this value at correct position in "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". You have sorted values already. But you dont need sorting to paste new tag *"route_ref:De_Lijn:10"="yes". JOSM may sort or even hide tags for you, don't do computer job.* Also you get benefits from taginfo if your keys *route_ref:De_Lijn: *are popular, you can redirect taginfo users to wiki page about your project or tagging scheme. Back to your problem. After tags are in database, you may develop universal plugin for JOSM that will do very simple thing: for defined set of tags (*route_ref:De_Lijn:, fuel:, cruisine: *and others) it will glue their values together only for you. You may edit them as usual, but after it should somehow (it will be less tricky than everyone learn regex and ;; escaping) convert this string to the original keys. Does this make sense for you? Will you adapt this approach? 2015-01-21 13:42 GMT+03:00 Jo <winfi...@gmail.com>: > 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 > >
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
