addaccess / setaccess = either it's not working, or I don't understand it! - merge-roads branch So, today for the first time since a couple of weeks I had full day time to work through mkgmap changes, and I must say I don't understand the addaccess / setaccess concept at all. mkgmap:access is far better, the intention of making styles-files easier by addaccess/setaccess definitely turned wrong, or I don't understand it... How can I mass replace the old rules? Or better, how can I replace this old rule at all? I don't see how this is possible now. e.g. ( mkgmap:access=no | mkgmap:access=private ) & ( mkgmap:bicycle=yes | mkgmap:bicycle=permissive ) {delete mkgmap:access} ? (XXXX | YYYY & ( mkgmap:bicycle=yes | mkgmap:bicycle=permissive ) {????} # I put mkgmap:bicycle here, because it makes much more sense than mkgmap:bike.... (setaccess=no | setaccess=private) & ( mkgmap:bicycle=yes | mkgmap:bicycle=permissive ) {????} ? 1. XXXX : testing for access=no is wrong, because I don't want to test on what has been in the data, but what value I previously set. And no - setting a second key to verify what happend using addaccess setaccess would completly destroy any making it simpler... Therefore I suppose now there is one term, and if I put it in {} then it means an action, but if it's not, then it means it is a test. Very very bad idea too. 2. YYYY: well as long as "setaccess private" works - and you can search for it by setaccess=private, it's still the same problematic case as above. 3. ???? {delete setaccess} what about if it was using add? It makes no sense at all. And as I often wrote before, there is a difference between setaccess=yes and setaccess not existing. 4. As for a complete rework, I still don't see why the old system needed to be changed! There is no new functionality at all, mkgmap didn't get faster but slower, and style-files get much more complicated! If it's about making it possible to merge more roads, then I still don't see it. mgkmap shouldn't look if the tags in the data are the same, but if the outcome as it will be put into the map, is the same. So yes, also for the old notation a highway=primary & bicycle=private should be merged with a highway=primary & bicycle=no, but not with highway=primary & bicycle=yes... I reworked my style to use mkgamp:?? notation, so going back will mean again lot's of hours of work (or alternatively trying to backport all changes since that change), so I would be happy if we keep mkgmap:??, but I think the easiest would be to keep the old notation system, and add a file to the style-file where you can define how e.g. private or destination are handled (yes or no). -- keep on biking and discovering new trails Felix openmtbmap.org & www.velomap.org