April 2014 - mkgmap-dev - The mkgmap lists

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

Restriction relations and additional (cycle) ways
by GerdP 01 Apr '14

01 Apr '14

Hi, the via-ways branch is almost done, but I wonder what to do when make-opposite-cycleways is used or when the style creates multiple routable lines for one OSM way. The Garmin format for restrictions reqires nodes and arcs. The OSM format specifies from and to ways and via nodes or ways. Assume that a via way of an only_left restriction has also an opposite cycleway. Should mkgmap create all possible combinations of restrictions to make sure that also bicycles are only routed left ? Or should it make sure that the bicycle ways are not affected? Gerd -- View this message in context: http://gis.19327.n5.nabble.com/Restriction-relations-and-additional-cycle-w… Sent from the Mkgmap Development mailing list archive at Nabble.com.

5 17

Possible mkgmap GPL v2 license infringement
by Paulo Carvalho 01 Apr '14

01 Apr '14

> > ---------- Mensagem encaminhada ---------- > From: Steve Ratcliffe <steve(a)parabola.me.uk> > To: Development list for mkgmap <mkgmap-dev(a)lists.mkgmap.org.uk> > Cc: > Date: Mon, 31 Mar 2014 22:41:54 +0100 > Subject: Re: [mkgmap-dev] Possible mkgmap GPL v2 license infringement > > Hi > > Recently "Projeto Tracksource" released a new version of its TSuite tool >> with Garmin compilation feature. >> > > The jar contains a version of cgpsmapper as a windows executable. > I couldn't find (or see *shame*) it. I used Ark to inspect the Jar contents. Thanks for the finding. > I also believe that they bought the source to cGPSMapper, so it may > be a modified version. > That's right. They bought the source code. > > I do not see anything that suggests they are using mkgmap. > Reading the software manual, it states that it only works on Windows, which explains the .EXE you found. regards, Paulo

1 0