On 03.10.2013 20:50, WanMil wrote:
Well to make styles easier, maybe we could have a third command which works like a in between add and set. That command would only set mkgmap: tags, in case they are not default, therefore you could later on in the style run rules with differentiation between set explicitely by set, and other set implicitely... Example 2. (to keep in order with the previous email). highway=track, bicycle=yes, foot=no
2.1 bicycle=* {setdifferent mkgmap:bicycle='${bicycle}' } foot=* {setdifferent mkgmap:foot='${foot}' }
-- result: mkgmap:foot=no; mkgmap:bicycle=UNSET
2.2. bicycle=* {set mkgmap:bicycle='${bicycle}' } foot=* {set mkgmap:foot='${foot}' }
-- result: mkgmap:foot=no; mkgmap:bicycle=yes
2.3 bicycle=* {adddifferent mkgmap:bicycle='${bicycle}' } foot=* {adddifferent mkgmap:foot='${foot}' }
-- result: mkgmap:foot=no; mkgmap:bicycle=UNSET
However I'm not so sure this is really needed. My main problem when rewriting the style was that I have different road_class or road_speed if an access type like bicycle or motorcar or foot is private / designated / .... Therefore I couldn't just simply replace my old set / add commands, as in the branch only NO matters. Everything else is effectively trashed. Previously I knew that private would mean no, So I could write different rules for it somewhere in the style, while still having the outcome of private meaning no is set. Now I have to make sure that I look in rules at the original bicycle or foot values, but write all {] content for both bicycle and mkgmap:bicycle as example, because otherwise the result is different than before. As private is not NO anymore, getting old behavior meant rewriting quite a lot of lines manually instead of simple CRTL-H exchanging. The setdiffferent idea is not really related to the mergeroads branch it's rather something that I already in past had to write a bit more complex rules and replicate tags to achieve the wanted result of knowing original value of a tag, while setting it to something new.
Hi Felix,
first start with the easiest thing: I think the setdifferent action is superfluous. You could easily change your rules to
2.1 bicycle=no {set mkgmap:bicycle='no' } foot=no {set mkgmap:foot='no' }
-- result: mkgmap:foot=no; mkgmap:bicycle=UNSET
2.2. bicycle=* {set mkgmap:bicycle='${bicycle}' } foot=* {set mkgmap:foot='${foot}' }
-- result: mkgmap:foot=no; mkgmap:bicycle=yes
2.3 bicycle=no {add mkgmap:bicycle='no' } foot=no {add mkgmap:foot='no' }
-- result: mkgmap:foot=no; mkgmap:bicycle=UNSET
Regarding that in the branch only the value 'no' matters: Would it help if I add an option "nonaccessvalues" where you can define which values are read as "no access"? So to have the same behaviour as the trunk you would set the option --nonaccessvalues=no,private yes - that would help and simplify a lot.
Anyhow I haven't fully understood why you couldn't add rules to the start of your style: access=private { set mkgmap:access='no' } bicycle=private { set mkgmap:bike='no' } ... So you still have access to the original values and you have set the access flag to 'no'. the problem is that other rules "further down the lines" file check on whether mgmap:access=no is set or not set. Currently with private not being no, I would need to check on both private and no, which makes the style-file longer/more complicated. The main problem arises due to access=private being set wrong in OSM in at least 50% of its use cases (my guess).
Signs like the German "Privatstraße - Zufahrt verboten" (Private Road, Drive in no allowed) are tagged as access=private, while they should actually be vehicle or motor_vehicle=private. Also people interprete the simple sign "Privatstraße (Private Road)" as access=private - even if access is allowed, because they confuse ownership with access rights. In other cases there might actually be bicycle=no signs, but in reality no-one cares because they are not executed, and so on... So just translating what is in OSM to mkgmap:access doesn't work. On the other hand we also need to make sure that physical hinderance (e.g. tracktype, sac_scale, mtb:scale, and so on) are translated into mkgmap:access. So yes - having a table which keys are read as no, would be great. Then one could also set mkgmap:access=impossible (in order to separate it from "not allowed") for checks, and in the end end up with both being unroutable.
WanMil