- mkgmap-dev - The mkgmap lists

Commit: r3169: Fix the e-road rule in the relations file
by svn commit 05 Apr '14

05 Apr '14

Version mkgmap-r3169 was committed by wanmil on Sat, 05 Apr 2014 Fix the e-road rule in the relations file

1 0

Missing } in relations of default style?
by WanMil 05 Apr '14

05 Apr '14

Hi, The relations file of the mkgmap default style seems to have a problem. The apply rule of the e-road rule has an open bracket { only. But it is not closed and the rule never seems to be executed. Closing it the style parser complains. Using the following single rule in the relations file the parser complains: route=road & network=e-road { apply { add ref='${ref}'; add int_ref='${int_ref'}; add network='e-road'; } } Error in style: Error: (relations:3): Incomplete expression, just a single symbol: } What's wrong here? Parser or style or?? WanMil

1 1

Commit: r3168: improve WrongAngleFixer: before merging nodes that are not very close,
by svn commit 05 Apr '14

05 Apr '14

Version mkgmap-r3168 was committed by gerd on Sat, 05 Apr 2014 improve WrongAngleFixer: before merging nodes that are not very close, check that a nearly straight line goes through both nodes and that this line is improved by the merge. In rare cases, nodes where merged causing distorted lines. The merge should happen in a situation like this: b b aaaaaaaaaaaaaaaaaaaaaaaaaaaa c c Road a is straight, roads b and c are connected to it with nodes that are close together. If a is not perfectly horizontal, the two connection points might be rounded to very different positions, so that road a is zig-zagging in the map. The merge helps to avoid this.

1 0

Found a problem in the WrongAngleFixer
by Gerd Petermann 03 Apr '14

03 Apr '14

Hi all, while looking at the special cases in the via_ways branch I found a problem in the WrongAngleFixer. Example: Very short ways like http://www.openstreetmap.org/way/25452137 are causing distorted lines and maybe incorrect routing info. Another case: Four barriers within ~ 2 sqare meter: http://www.openstreetmap.org/node/2409136324 (see attached picture) Looking at this now ... Gerd

1 0

Is mkgmap now producing fully compatible maps built at resolution=23 instead of 24?
by Felix Hartmann 03 Apr '14

03 Apr '14

I just wondered, is mkgmap now producing fully working maps if the highest resolution is 23 instead of 24? (meaning no problems with autorouting, no problems with simplyfing filters, address search and so on?). BTW - if it is - it would be cool if one could specify "0x1c resolution highest" or "0x1c resolution X" instead of 24 or 23 to quickly change between producing a map with resolution 24 and 23 for testing... (I know this could be done with using level instead - but for me using resolution is easier because when editing a style-file I can assess the outcome much easier than needing to remember with level is which resolution. Also it's easier to play around with levels that way - the only problem is that each time I would need to run a script to change resolution 24 to 23 as I don't want to do this in the style-file I use for editing itself as it's a way of no return if you want to have 23 and 24 in the map again).. Or is it possible to replace just "resolution 24" in the style-file with "level 0" while keeping all other at resolution ?? and still using the options file to get the other resolution ?? assigned to their proper level? -- keep on biking and discovering new trails Felix openmtbmap.org & www.velomap.org

2 2

motor_vehicle=*
by GerdP 02 Apr '14

02 Apr '14

Hi all, the default style contains this line: motor_vehicle=* { add mkgmap:car='${motor_vehicle}' } My understanding is that motor_vehicle includes mkgmap:truck, mkgmap:car, mkgmap:bus, mkgmap:taxi, mkgmap:emergency, and mkgmap:delivery, not just mkgmap:car. So motor_vehicle=no means something like add mkgmap:foot=yes add mkgmap:bicycle=yes addaccess no Is that correct? If yes, please propose a rule for this. See also vehicle=* { add mkgmap:car='${vehicle}'; add mkgmap:bicycle='${vehicle}' } Gerd -- View this message in context: http://gis.19327.n5.nabble.com/motor-vehicle-tp5802026.html Sent from the Mkgmap Development mailing list archive at Nabble.com.

1 0

barrier & access
by Minko 02 Apr '14

02 Apr '14

In the default style the access for a gate has this rule: barrier=gate { add mkgmap:bicycle=yes; add mkgmap:foot=yes; addaccess no; set mkgmap:road-speed=0; } In osm a gate can have this rule: foot=yes access=no To me it looks like mkgmap is giving bicycles by default access through this gate. Or is the rule addaccess no blocking this?

3 4

Commit: r3160: Fix 'Invalid rule' problem with rules containing OR terms.
by svn commit 02 Apr '14

02 Apr '14

Version mkgmap-r3160 was committed by steve on Wed, 02 Apr 2014 Fix 'Invalid rule' problem with rules containing OR terms. Fairly complex rules that did not start with a definite key=value term and that also included some terms that were or'ed together would not always be resolved correctly and resulted in an error. A group of alternatives is now weighted according to the term with the worst selectivity, not the best. So alternatives will only be brought to the front if they are all definite key=value terms and other terms are less selective. Also we arrange (A&B)&C to A&(B&C) so that the first term can be recognised properly.

1 0

Commit: r3159: Fix the reported line number in style messages.
by svn commit 02 Apr '14

02 Apr '14

Version mkgmap-r3159 was committed by steve on Wed, 02 Apr 2014 Fix the reported line number in style messages. Blank lines were being combined and so only one was counted.

1 0

invalid rule expression
by Minko 02 Apr '14

02 Apr '14

This rule does not work: highway ~ '(secondary|tertiary|unclassified|residential|minor|living_street|service)' & oneway=* & (cycleway=opposite | cycleway=opposite_lane | cycleway=opposite_track | oneway:bicycle=no | bicycle:oneway=no ) {set bicycle=no; set mkgmap:cycleway=yes} Only if I put oneway=* first, it works, why? oneway=* & highway ~ '(secondary|tertiary|unclassified|residential|minor|living_street|service)' & ( cycleway=opposite | cycleway=opposite_lane | cycleway=opposite_track | oneway:bicycle=no | bicycle:oneway=no ) {set bicycle=no; set mkgmap:cycleway=yes} The error message is: Error in style: Error: (lines:119): Invalid rule expression: (((($cycleway='opposite')|(($cycleway='opposite_lane')|(($cycleway='opposite_track')|(($oneway:bicycle='no')|($bicycle:oneway='no')))))&$oneway=*)&($highway~'(secondary|tertiary|unclassified|residential|minor|living_street|service)'))

2 9