March 2014 - mkgmap-dev - The mkgmap lists

problems with the add-poi-to-lines option
by Gerd Petermann 26 Mar '14

26 Mar '14

Hi all, I've reviewed the problem reported by Stephen: http://gis.19327.n5.nabble.com/ontario-canada-maps-tp5798080.html The error message is: There is not enough room in a single garmin map for all the input data The .osm file should be split into smaller pieces first. The problem has at least two reasons: 1) A mapper in that area prefers to create extremely detailed ways like this http://www.openstreetmap.org/way/188276794 (the river is ~ 181m long and has 166 points, and many roads in that area are alike) 2) Stephen uses a style that adds more or less each generated POI to the map. With r3128 I've committed a patch that detects duplicate points (in Garmin precision), but that doesn't solve the problem completely, and it only works when --preserve-element-order is active. I don't know why Stephen wants all these POI, so maybe the tags like mkgmap:line2poitype=start, mkgmap:line2poitype=end, and mkgmap:line2poitype=mid are not helping him. I think a better solution would be to change the POIGeneratorHook so that it generates POI with a minimum distance of e.g. 5m, or at least no equal points. I remember that this was discussed before, but couldn't find it in the archives. Gerd

1 0

Commit: r3128: apply (adapted version of) del-dup-POI-v1.patch
by svn commit 26 Mar '14

26 Mar '14

Version mkgmap-r3128 was committed by gerd on Wed, 26 Mar 2014 apply (adapted version of) del-dup-POI-v1.patch Detect POI with identical tags and coordinates (in Garmin units) and ignore them. These are typically generated for highly detailed ways by the --add-pois-to-limes option. Two possible warnings: for generated POI: ignoring duplicate (generated) POI at ... for others: ignoring duplicate POI http://www.openstreetmap.org/browse/node/...

1 0

Commit: r3127: apply disappearing-roads-v1.patch
by svn commit 26 Mar '14

26 Mar '14

Version mkgmap-r3127 was committed by gerd on Wed, 26 Mar 2014 apply disappearing-roads-v1.patch correct DP filter to fix problem with disappearing parts of lines at lower resolutions.

1 0

Commit: r3126: allow bicycle on highway=path
by svn commit 26 Mar '14

26 Mar '14

Version mkgmap-r3126 was committed by gerd on Wed, 26 Mar 2014 allow bicycle on highway=path

1 0

options make-all-cycleways and make-cycleways
by Gerd Petermann 25 Mar '14

25 Mar '14

Hi all, I think this was discussed before, but I don't remember the result. I must confess that I don't fully understand the idea of these two options while make-opposite-cycleways seems to make sense. To allow bicycle traffic for a road that is NOT a oneway, why do we add an additional way? The tag bicycle=yes should be enough for that? Gerd

2 1

question regarding MapRoad
by GerdP 25 Mar '14

25 Mar '14

Hi Steve, I'd like to change the way how MapRoad objects are handled in the sub division split process. Current implementation is like this: 1) StyledConverter creates a MapRoad instance with max. 250 points, if a road has more points, multiple instances are created, each with its own RoadDef. 2) When the sub divisions are created, a MapRoad is never split, so the final result is that each instance is written to exactly one sub division. The Garmin format seems to imply that we should rather split the MapRoad to match a given bbox of a sub division. This will produce smaller img files because the offsets to the sub division centers are smaller, and if we allow to start with MapRoad instances having > 250 points, we also have fewer NOD entries. I tried to implement this, but I can't find a nice way to store the information about the order of the segments of a road. This is needed when finally the RoadDef.addPolylineRef() method is called. I think that we either have to make sure that each part of a road is processed in the correct order, or we have to restore the order after all the filters where used. (For the different levels, a road will be split into different parts, if a road goes out and in we can have multiple segments in one sub div, not directly connected to each other) I have no idea yet how to do this. Can you help? Gerd -- View this message in context: http://gis.19327.n5.nabble.com/question-regarding-MapRoad-tp5781633.html Sent from the Mkgmap Development mailing list archive at Nabble.com.

4 10

highway=path only for pedestrians?
by Gerd Petermann 25 Mar '14

25 Mar '14

Hi all, for a way that has only the tag highway=path the default style (lines) rule highway=path {set highway=footway} fires. I think that's wrong, the wiki says "A route open to the public which is not intended for motor vehicles, unless so tagged separately." so we should also allow bikes. The confusing thing is that the access include has this line: highway=path { add foot=yes; add bicycle=yes; add access=no } but because the other rule fires first, this is ignored and highway=footway { add foot=yes; add access=no } is used. AFAIU the rule highway=path {set highway=footway} should be removed. Gerd

2 2

[Patch v4] distorted lines with make-opposite-cycleways
by Gerd Petermann 25 Mar '14

25 Mar '14

this is version 4 of the patch for this problem: http://gis.19327.n5.nabble.com/link-pois-to-ways-tags-tp5800124p5800575.html It works like version 3, but avoids to save the artificial cycle way with an id that might exist in the input file (although that is very unlikely) I am not sure if this option helps a lot. It seems that both MapSource and Basecamp have problems to find the cycle way. If I enter a route that starts on a cycle way created by this option, I am (sometimes) first forced to go onto the normal road, just to be asked to take a u-turn onto the cycleway again. This happens even if I select the switch "avoid u-turns". The attached files show that. The same problem in Basecamp. I also tried to forbid bicycle routing on ways for which an additional bicycle way is created, but found no difference. Any ideas? Gerd

4 5

mkgmap --check-styles and line count
by Bernd Weigelt 24 Mar '14

24 Mar '14

Hi my style include a lot of rules like this: highway=footway [0x1200d resolution 23-23 continue] highway=footway [0x1100d resolution 24 continue] highway=footway & (bicycle=designated | bicycle=permissive | bicycle=official | bicycle=yes) [0x0a resolution 24 road_class=0 road_speed=1] highway=footway [0x0d resolution 24 road_class=0 road_speed=0] IMHO mkgmap count four lines, is that correct? now it is difficult to find the error, if the files includes up to 700 lines, i think, there are some larger styles around the world mkgmap tells: Error in style: Error: (lines:393): Stack size is 0 but the line with the error is line 485 in the style file my error was to use '[' instead '(' ;-) Bernd

4 6

Finalize section not working as expected
by franco_bez 24 Mar '14

24 Mar '14

I got a very nasty bug here. IMHO it must be somehow related to the finalize section in the lines file of the style. http://www.openstreetmap.org/#map=16/47.9114/10.5862 When routing along the bicycleway along the "OAL12" from the roundabout to Irsee. Choosing "Mountainbike" or "Tourbike" as Activity and "shortest distance" as Calculating method always leads me on a heavy Trail. I have rules in the style that set "bicycle=no" for this trail, but they do not seem to have any effect unless I include them BEFORE the garmin type gets assigned. In the finalize section they seem to be ignored. At least on my OREGON 550 with latest Firmware. A few screenshots: <http://gis.19327.n5.nabble.com/file/n5800737/Roundabout82.bmp> <http://gis.19327.n5.nabble.com/file/n5800737/2-Target_in_Irsee127.bmp> <http://gis.19327.n5.nabble.com/file/n5800737/3-Choose_Tourbike_or_Mountainb…> <http://gis.19327.n5.nabble.com/file/n5800737/4-Choose_short_distance141.bmp> <http://gis.19327.n5.nabble.com/file/n5800737/5-Routing_broken_why_182.bmp> <http://gis.19327.n5.nabble.com/file/n5800737/6-Routing_correct_with_hacked_…> I composed a test case http://files.mkgmap.org.uk/download/188/test_case.tgz this is the only change in the style that makes routing work: / test_cases/mystyles$ diff -uws bikemap_style_hacked/ bikemap_style Gemeinsame Unterverzeichnisse: bikemap_style_hacked/inc und bikemap_style/inc. Dateien bikemap_style_hacked/info und bikemap_style/info sind identisch. diff -uws bikemap_style_hacked/lines bikemap_style/lines --- bikemap_style_hacked/lines 2014-03-23 13:08:03.295102817 +0100 +++ bikemap_style/lines 2014-03-22 19:20:03.000000000 +0100 @@ -534,8 +534,6 @@ #------------------------------------------------------------------------------ # path -# HACK include access rules before path rules -include 'inc/compat_access' ; highway=path | highway=trail | highway=byway [0x11012 resolution 24 continue] Dateien bikemap_style_hacked/options und bikemap_style/options sind identisch. Dateien bikemap_style_hacked/points und bikemap_style/points sind identisch. Dateien bikemap_style_hacked/polygons und bikemap_style/polygons sind identisch. Dateien bikemap_style_hacked/README und bikemap_style/README sind identisch. Dateien bikemap_style_hacked/relations und bikemap_style/relations sind identisch. Dateien bikemap_style_hacked/version und bikemap_style/version sind identisch. / -- View this message in context: http://gis.19327.n5.nabble.com/Finalize-section-not-working-as-expected-tp5… Sent from the Mkgmap Development mailing list archive at Nabble.com.

4 13