- mkgmap-dev - The mkgmap lists

[Patch v5] correct make-cycleways
by Gerd Petermann 27 Mar '14

27 Mar '14

Hi all, this is version 5 of the patch for this problem: http://gis.19327.n5.nabble.com/link-pois-to-ways-tags-tp5800124p5800575.html It creates the cycleway first (with access for bicycles only) and forbids bicycle for the normal way. I've also added support for oneway=-1 and oneway=reverse in combination with cycleway=opposite and oneway:bicycle=no and bicycle:oneway=no in combination with a valid oneway=* tag are treated like cycleway=opposite. This seems to solve all known issues with routing in Basecamp and MapSource. Thanks Minko for the hint :-) Gerd

6 24

dissapearing roads
by Michał Rogala 26 Mar '14

26 Mar '14

Hi! Today I've noticed a very strange behavior of mkgmap. Consider this road: http://www.openstreetmap.org/#map=16/52.0071/20.2446 it's a tertiary road. My rules for tertiary roads are: highway=tertiary {set mkgmap:no_name=yes} [0x1101d resolution 18-18 continue] highway=tertiary {set mkgmap:no_name=yes} [0x1101b resolution 20-20 continue] highway=tertiary {set mkgmap:no_name=yes} [0x1101b resolution 21-21 continue] highway=tertiary {set mkgmap:no_name=yes} [0x05 resolution 22-22 continue] highway=tertiary {name '${name}'} [0x05 road_class=1 road_speed=3 resolution 23] (if mkgmap:no_name is set, <finalize> scripts are not executed, so name for road is not assigned). As you may suppose, tertiary roads should be seen on almost any zoom level. MapSource on 300m (level 23) zoom: http://imgur.com/LHptaRJ MapSource on 500m (level 22) zoom: http://imgur.com/1Aa4SL9 Part of the road disappears...... This is not related to any possible MapSource or Garmin (tested on hardware) bug with road rendering. I opened IMG file in MapEdit and it really this lacks road on levels 18-22. I found that this bug is related to --preserve-element-order parameter. When it's set - everything is fine. Without it, road disappears. best regards Michal Rogala

8 33

Commit: r3129: instead of removing duplicate POI, just don't create them.
by svn commit 26 Mar '14

26 Mar '14

Version mkgmap-r3129 was committed by gerd on Wed, 26 Mar 2014 instead of removing duplicate POI, just don't create them. Reverses changes from r3128.

1 0

Should mkgmap report overly detailed ways?
by Gerd Petermann 26 Mar '14

26 Mar '14

Hi all, I don't know if their is a rule for mappers, but the typical way has not more than 2 nodes on a segment that is < 3m long. Some routines (e.g. the new WrongAngleFixer) in mkgmap have a lot of work with ways that are heavyly detailed. It would be quite easy to report them like this: Warning (POIGeneratorHook): e:\osm_out_work\ontario\20140302_095212\63240011.o5m: highly detailed way http://www.openstreetmap.org/browse/way/100564006 has 362 nodes and is only ~ 77m long The question is: Would anybody use this info reduce the details in OSM? Gerd

4 5

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