On 17.10.2013 18:20, WanMil wrote:

...

addaccess / setaccess = either it's not working, or I don't understand it! - merge-roads branch

It's not yet documented so it's not a shame :-)

mkgmap:access is no longer used.

addaccess no is a shortcut for add mkgmap:foot='no'; add mkgmap:car='no'; add mkgmap:bike='no'; add mkgmap:bus='no'; add mkgmap:taxi='no'; add mkgmap:truck='no'; add mkgmap:emergency='no'; add mkgmap:delivery='no'; add mkgmap:throughroute='no';

setaccess no is a shortcut for set mkgmap:foot='no'; set mkgmap:car='no'; set mkgmap:bike='no'; set mkgmap:bus='no'; set mkgmap:taxi='no'; set mkgmap:truck='no'; set mkgmap:emergency='no'; set mkgmap:delivery='no'; set mkgmap:throughroute='no'; yes but that requires much more space. And while add and set is possible to be used; the same does not apply to delete. So far set mgkmap:access would just set this tag, not actually at the time of setting it, unset the other keys.

Without this shortcut, this is not possible anymore! The following example cannot be achieved without it! highway=private & route=bicycle & tracktype=grade2 tracktype=grade2 {set mkgmap:car=no} highway=private {set mkgmap:access=no} route=bicycle {delete mkgmap:access } result until now: the highway is mkgmap:car=no, result without shortcut: the highway is open for all traffic. Really, this shortcut is needed. I cannot replace it in my styles (except by adding a separate key, and check for that separate key each time I do any access/bicycle/car/whatever operation.... Why do you want to remove it so badly? Is it a performance hog? I can test that tomorrow - but I wouldn't believe that it impairs performance...

Mapping multiple values to 'no' can be easily done with the subst operator:

bicycle=* { set mkgmap:bike='${bicycle|subst:private=>no}' }

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 It's not so many lines in my code which get more complicated.

Please have a look at the inc/access file in the default style. It might give you some ideas how to assign the access fields.

WanMil

...

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

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

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

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@gmail.com To: wmgcnfg@web.de; mkgmap-dev@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@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Hi Felix, I think I do now understand a bit better why you are so keen to keep the mkgmap:access handling. Two solutions come into my mind: 1. ======================== Add the mkgmap:access handling to the java code. If any of the mkgmap:bicycle etc. tags are not set the value of the mkgmap:access is used. 2. ======================== Create a new finalizer style file. The finalizer style file contains actions only (no element type definitions). It is executed each time an element type definition matches. I don't know how to implement that in the style system but it could be worthy to check. You might implement the mkgmap:access behaviour yourself: Example: lines === ... access=no | access=private { set mkgmap:access=no } bicycle=* { add mkgmap:bicycle='${bicycle}' } ... highway=track [0x0a road_class=1 road_speed=2 resolution 22 continue] highway=unsurfaced [0x0a road_class=0 road_speed=1 resolution 22] finalizer === mkgmap:access=* { addaccess '${mkgmap:access}' } The upper example would have to be written with lines file only: lines === ... access=no | access=private { set mkgmap:access=no } bicycle=* { add mkgmap:bicycle='${bicycle}' } ... highway=track & mkgmap:access=* { addaccess '${mkgmap:access}' } [0x0a road_class=1 road_speed=2 resolution 22 continue] highway=track & mkgmap:access!=* [0x0a road_class=1 road_speed=2 resolution 22 continue] highway=unsurfaced & mkgmap:access=* { addaccess '${mkgmap:access}' } [0x0a road_class=0 road_speed=1 resolution 22] highway=unsurfaced [0x0a road_class=0 road_speed=1 resolution 22] I guess that also might be useful for other purposes. =============================================================== By the way: I did have a short look into your old style file. I started with a delete so I am sure you knew about the delete command ;-) Some rules can be removed because they will never be executed. Check with taginfo to identify non existing tag values. Probably this will improve execution time a bit. Examples: highway=service_footway highway=Feldweg highway=residental highway=cycleroad highway=cyclestreet ... WanMil _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev