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

Sat Oct 26 08:41:12 BST 2013

Hi WanMil,

would it be possible to code a translator? 
Input: style rules for trunk, 
Output: style rules for merge-roads branch

Such a translator could also be used to find dead code in rules.

Gerd

Date: Fri, 25 Oct 2013 15:17:26 +0200
From: extremecarver at gmail.com
To: wmgcnfg at web.de; mkgmap-dev at lists.mkgmap.org.uk
Subject: Re: [mkgmap-dev] Request to rollback at least rev 2747 - or give the access part a complete rework, as of right now it's broken...

Sorry for not answering so far, didn't have time...

On 17.10.2013 20:49, WanMil wrote:
> Let's go through your examples:
>
> highway=track, tracktype=grade2, bicycle=no, foot=private
>
> 1.
> highway=*  tracktype=grade2 {set mkgmap:bicycle=yes}
> highway=* & bicycle=no {add mkgmap:access=no}
> --- result bicycle=yes - foot=yes, all other set to no (there is no 
> rule for foot = private, value is set, so add cannot overwrite it)
>
> Rules that create your results with branch r2763:
> highway=*  tracktype=grade2 {set mkgmap:bicycle=yes}
> foot=* { add mkgmap:foot='${foot|subst:private=>no}' }
> highway=* & bicycle=no {addaccess no}
This change is not intuitive, and because the rules to recreate previous 
processing are just result based on the input. There is no way to 
automatically change to this behaviour by CTRL-H replacing. It means 
more or less rewriting a style from scratch.
Before knowing that foot=private exists, you simply cannot write a rule 
for it. Now with 2000+ lines of rules - you cannot add basically 
everywhere rules about treatment of private. Else a 2000+ lines line 
files becomes a 4000+ lines file, because directly overwriting private 
with no is impossible, without inflicting later places.
The only real solution is to add a rule (and that rule needs to be after 
every place where you set some value to private) like
foot=private { add mkgmap:foot=no; add addtag:private:foot=yes }
then each time you test for foot with implications if it was private, 
check whether addtag:private:foot=yes is set too.

Still, this doesn't bother me much, as at least for my style I can 
circumvent this problem with maybe 200-300 lines of new rules as I don't 
often need to know wheter it is really private or no (I think so, I'm 
sure will overlook some small places, but 99% should still work...).

Additionally -  for everyone not fully at ease with regex, 
"subst:private=>" is just plain madness. I think that needs much more 
explaining than an additional file where you could set what values are 
regarded as no.
>
>
> 1.1
> highway=*  tracktype=grade2 {set mkgmap:bicycle=yes}
> highway=* & bicycle=no {set mkgmap:access=no}
> --- result all access types no, as the second rule comes later and set
> should always overrule.
>
> Rules that create your results with branch r2763:
> highway=*  tracktype=grade2 {set mkgmap:bicycle=yes}
> highway=* & bicycle=no {setaccess no}
>
no problem as long as there is not sometimes later a delete 
mkgmap:access in the style.
>
> 1.2
> highway=*  tracktype=grade2 {add mkgmap:bicycle=yes}
> highway=* & bicycle=no {set mkgmap:access=no}
> --- result all access types no, as the second rule comes later and set
> should always overrule. As bicycle is only add command - it would be no
> anyhow.
>
> Rules that create your results with branch r2763:
> highway=*  tracktype=grade2 {add mkgmap:bicycle=yes}
> highway=* & bicycle=no {setaccess no}
>
>
> 1.3
> highway=* & bicycle=no {set mkgmap:access=no}
> highway=*  tracktype=grade2 {set mkgmap:bicycle=yes}
> -- bicycle=yes, all other access types no. later rule overrules earlier
>
> Rules that create your results with branch r2763:
> highway=* & bicycle=no {setaccess no}
> highway=*  tracktype=grade2 {set mkgmap:bicycle=yes}
>
>
> 1.4a
> highway=*  tracktype=grade2 {set mkgmap:access=no;set 
> mkgmap:bicycle=yes; }
> -- Does mkgmap keep track of order of commands set within one bracket??
> Well here the case is quite clear anyhow. Set access=no but bicycle=yes
>
> Rules that create your results with branch r2763:
> highway=*  tracktype=grade2 {setaccess no;set mkgmap:bicycle=yes; }
>
>
> 1.4b - heavily conflicting:
> highway=*  tracktype=grade2 {set mkgmap:bicycle=yes; set 
> mkgmap:access=no}
> -- Does mkgmap keep track of order of commands set within one bracket??
> If yes the logical answer would be to set all types to no. If not, then
> bicycle=yes and all other =no would be expected.
>
> Rules that create your results with branch r2763 (all no):
> highway=*  tracktype=grade2 {set mkgmap:bicycle=yes; setaccess no}
>
>
> 1.5
> bicycle=* {set mkgmap:bicycle='${bicycle}' }
> foot=* {set mkgmap:bicycle='${foot}' }
> highway=* & tracktype=grade2 {add mkgmap:access=yes}
> -- foot = no (there is no rule to convert private to no); bicycle = no;
> all other types set to yes.
>
> Rules that create your results with branch r2763:
> bicycle=* {set mkgmap:bicycle='${bicycle|subst:private=>no}' }
> foot=* {set mkgmap:bicycle='${foot|subst:private=>no}' }
> highway=* & tracktype=grade2 {addaccess yes}

> 1.6
> bicycle=* {set mkgmap:bicycle='${bicycle}' }
> foot=* {set mkgmap:foot='${foot}' }
> highway=* & tracktype=grade2 {set mkgmap:access=yes}
> -- well last rule is set all to yes, so previous rules don't apply. All
> types to no.
>
> Rules that create your results with branch r2763:
> bicycle=* {set mkgmap:bicycle='${bicycle}' }
> foot=* {set mkgmap:foot='${foot}' }
> highway=* & tracktype=grade2 {setaccess yes}
>
> (Result: all types are set to yes).
>
> I would say: well done - no unresolved problems ;-)
>
> Please send me one more example to convince me that a new shortcut
> removeaccess (which performs { delete mkgmap:bicycle; delete 
> mkgmap:foot; ...) is useful and required.

No I don't need a shortcut removeaccess which performs delete 
mkgmap:bicycle; and so on. If you would think that, then you didn't 
understand what I need.
I have about 1000 lines of code, which based on a) condition of way, and 
b) actual access rights, add or remove access rights. Sometimes full 
mkgmap:access sometimes only mkgmap:bicycle or other.

Now what I need is a way to remove setaccess itself, not it's outcome. 
If that would happen, the access rights in the map would already be broken.

I need the behaviour to be able to write set mkgmap:access=yes or 
set:mkgmap:acccess=no WHICH DOESN'T HAVE ANY INFLICTIONS ON OTHER KEYS 
LIKE MKGMAP:BICYCLE OR MKGMAP:FOOT and so on.
Basically I need a full separation between mkgmap:access and 
mkgmap:bicycle which is only resolved at the time of writing 0x* , not 
before.

E.g. some of the rules I'm using:
( mkgmap:access=no | mkgmap:access=private | mkgmap:access=destination ) 
& ( agricultural=yes | forestry=yes ) { delete mkgmap:access }
( mkgmap:bicycle=no | mkgmap:bicycle=nope ) &  ( agricultural=yes | 
forestry=yes ) {set mkgmap:bicycle=yes; set mkgmap:access=yes; set 
mkgmap:unpaved=1}

( mkgmap:access=permissive | mkgmap:access=designated | 
mkgmap:access=official ) & (( mkgmap:bicycle=* & mkgmap:bicycle!=no & 
mkgmap:bicycle!=nope )|(mkgmap:bicycle!=*)) {add mkgmap:access=yes}
bicycle=dismount & highway!=footway & highway!=pedestrian {set 
mkgmap:bicycle=yes; add bicycle:dismount=yes} # This rule already relies 
later on checking for bicycle:dismount=yes - which will be done on 
pedestrian streets or footways

mkgmap:bicycle=no & highway!=* & route!=* & extremecarver5!=* & 
aerialway!=* {delete mkgmap:bicycle}

...... and so on. About 1000 lines all similar to them

I have attached a very old lines file of mine (last public version) just 
to give you an idea. of how many of those lines I actually use. This 
file is however of 3 years old, written at a time when delete didn't 
exist (or I didn't know it can be used), so still very different to 
today. By now my lines file is like 3 times as long and complex. And I 
have over 100 set mkgmap:access=yes/no  and over 30 delete:mkgmap:access 
lines. At the current state removing the ability to use mkgmap:access as 
a tag, simply means I would have to sit down for months, and rewrite my 
lines file, because it's impossible otherwise to get correct output as 
many rules depend on the order, and any change that means that there 
needs to be a different order, results in the impossibility of 
implementing the new mkgmap notation system.
>
> It's not that I don't want to implement new useful helpers. But I want 
> to get a understable, as simple as possible and coherent set of helpers.
> A good indication if this target could be reached is how complicate it 
> is to document it.
>
> At the moment a possible documentation might look like this:
> The mkgmap:*** specific access tags define for each road which vehicle 
> types are allowed to use this road. Each tag can be set separately. 
> But there are some helper actions that allow to handle all access tags 
> at once:
> addaccess <value>
> setaccess <value>
>
> Example:
> highway=motorway { addaccess yes; set mkgmap:foot=no; set 
> mkgmap:bicycle=no }
> => all vehicles can use the motorway, except pedestrians and bicycles.
>
> ...
>
> So I think it's possible to describe the behaviour in a few sentences 
> (good).
> There are no side effects because there is only one tag for one 
> vehicle class (good).
> The access rules are completely transparent because they are defined 
> via style file (good).
> The access classification can be freely defined (good).
> Most access tags are not loaded from OSM files if they are not used 
> (good - especially for creating special thematic overlays).
> Existing style files need to be adapted (could be better - but 
> sometimes this is neccessary)
I mainly agree, but adding mkgmap:access as it's own tag, wouldn't add a 
lot of documentation, while explaining a lot of regex to achieve what 
you could do with mkgmap:access is much longer.
Even more, the main problems of changing the way the access situation is 
handled will be not only explaining the change once, but reexplaining it 
to people who realize it later, and to people who asks specific question 
but built their knowledge based on "old notation" styles floating around 
in the net.
>
>
> WanMil
>
>
>> no sorry, but that change would really mean to loose functionality and
>> ease of use...
>> Basically I see no way to change my lines styles without spending at
>> least a week trying to work around not being able to set and delete
>> mkgmap:access anymore...
>>
>> The main problem is, that layout (type) and routing is not independent -
>> hence my lines style-file, but also others, got very complicated. If the
>> restrictions would be handled by a completly independant style-file, the
>> road_class/road_speed by one, and the layout by one, it would be easy
>> and straightforward to change such things. Sadly by the way garmin maps
>> work, this cannot be done, hence my lines file is now about 8000 lines
>> long, and loosing mkgmap functionality is really bad....
>>
>>
>> On 17.10.2013 18:35, WanMil wrote:
>>>> yes - but that is much more code than a simple {set 
>>>> bicycle=private} and
>>>> knowing it's interpreted as no. However while without mkgmap:access
>>>> shortcut, I basically cannot ever update mkgmap anymore, for private
>>>
>>> Do you want to blackmail me? Please stop rumbling around.
>>>
>>> This is a branch so it's under development. Which means it is not
>>> feature complete and if you argue comprehensible I don't mind changing
>>> things.
>>>
>>>> It's not so many lines in my code which get more complicated.
>>>
>>
>

-- 
keep on biking and discovering new trails

Felix
openmtbmap.org & www.velomap.org

_______________________________________________
mkgmap-dev mailing list
mkgmap-dev at lists.mkgmap.org.uk
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20131026/72858beb/attachment-0002.html>
-------------- next part --------------
_______________________________________________
mkgmap-dev mailing list
mkgmap-dev at lists.mkgmap.org.uk
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev