[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 10:30:26 BST 2013

Hi Gerd,

I am not sure if that's easily possible.
I think I will add a compatibility mode so that the old behaviour can 
still be used. This should not be too complicated.

In the end I think the real problem discussed here is that Felix 
invested a lot of time to translate his styles and is now unhappy with 
the fact that he adapted to a branch which is not functional complete. 
This means some functions are changed (mkgmap:access is removed) and 
others are new. I understand that this is not an ideal situation. But I 
don't want to implement (in my eyes) rules that are complicate to 
undestand just to solve this single requirement.

I am happy for any proposal that solves the problem.

I will read and think about Felix long post later on.

WanMil

> 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
>
>
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>

_______________________________________________
mkgmap-dev mailing list
mkgmap-dev at lists.mkgmap.org.uk
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev