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

Thu Oct 17 19:49:05 BST 2013

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}

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}

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.

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)

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.
>>
>