[mkgmap-dev] Request to rollback at least rev 2747 - or give the access part a complete rework, as of right now it's broken...

Wed Oct 16 16:16:15 BST 2013

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