- mkgmap-dev - The mkgmap lists

access=no on a cycleway doesn't work?
by Federico Cozzi 24 Nov '09

24 Nov '09

Hello, I am not subscribed to the list but I read an interesting message by Marko Mäkelä in the archive which I quote here: -------------------- > In my neighbourhood there's a highway=cycleway that is currently blocked > due to construction works. As the cycleway is still there (the cycleway > itself is not under construction), I tagged it access=no. However, > mkgmap still tries to route me over it. > Is that because styles file saying: "highway=cycleway {add access = no; > add bicycle = yes;" ? Or just use the "native" tags, but explicitly translate "access" to the vehicle-class tags and do not treat "access" specially in the core, e.g., access=no { add bicycle=no; add foot=no; add motorcar=no; add taxi=no; ... } -------------------- I do not know how mkgmap internally works, but I think that "access" should not even belong to the core! As far as I know Garmin maps only handle a fixed number of vehicle classes (e.g. motorcar, taxi, bicycle, etc.), not a general purpose catch-all vehicle class. Therefore the style file should say: access = no {add motorcar = no; add taxi = no; add bicycle = no; ...} highway = cycleway {add motorcar=no; add taxi=no; add bicycle = yes; ...} This way, a standard highway=cycleway with no additional tags would get bicycle=yes (and everything else = no); a highway=cycleway with access=no would get bicycle = no (and also everything else = no) Bye, Federico

5 11

Commit: r1404: Fixed bug that broke turn restrictions if via node was also a POI.
by svn commit 24 Nov '09

24 Nov '09

Version 1404 was commited by markb on 2009-11-24 00:15:11 +0000 (Tue, 24 Nov 2009) Fixed bug that broke turn restrictions if via node was also a POI. If a node was both a POI and the "via" node of a turn restriction, using the link-pois-to-ways option to make the POI's tags accessible when processing the way, broke the turn restriction processing because it did not replace the POI's Node object when the Coord was swapped out for a CoordPOI and so the Node continued to hold a reference to the original Coord and not the CoordPOI. The turn restrictions went on to use the original Coord from the original Node and as its identity didn't match the CoordPOI, the restrictions got skipped. No more.

1 0

Commit: r1403: Further tweaks to turn restriction diagnostic messages.
by svn commit 23 Nov '09

23 Nov '09

Version 1403 was commited by markb on 2009-11-23 11:43:51 +0000 (Mon, 23 Nov 2009) Further tweaks to turn restriction diagnostic messages.

2 1

Missing browse URL in turn restriction warning
by Marko Mäkelä 23 Nov '09

23 Nov '09

Mark, Could you please change the coordinates in this message to a browse URL for the node? Perhaps there could be a virtual method that would output the browse URL for the OSM primitive, or failing that, coordinates. WARNING (RestrictionRelation): Turn restriction http://www.openstreetmap.org/browse/relation/333165 'from' member should be a Way but is a NODE: 567968919 @ 60,27677/24,99587 Best regards, Marko

1 0

[PATCH v1] make DP filter avoid removing points located at nodes
by Mark Burton 22 Nov '09

22 Nov '09

v2 - based on r1402. ----------- Hi Felix, Please try the attached patch. I've tested it inasmuch that it doesn't blow up but whether it actually does the right thing when you have a routable and non-routable way from the same set of points, I don't know. Cheers, Mark

2 3

[PATCH v2] - round coordinates when zoomed out
by Mark Burton 22 Nov '09

22 Nov '09

v2 - also removes points with the same coordinates as the previous point. I know that this also gets done by the DP filter but it's very easy to do while rounding the coordinates and it does shrink the number of points to be processed by subsequent filters. This version of the patch should produce the same map as v1 of the patch. Unless anyone has any problems with this patch, I intend to commit it in a few days as I think the line gap-filling is worthwhile. ------- Having filled some gaps with that last little patch, I was wondering why I still had quite a few gaps when zoomed out. Obviously, the coords weren't being rounded to nearest given the zoom level. So, the attached patch does that rounding and, lo and behold, even more gaps have disappeared. Please give it a go, especially for maps that cross the equator/day line where the coords flip signs. Sure to be buggy but it's looking quite promising. BTW - this patch does not contain the last patch but they probably should be used together. Mark

3 7

Overview Map still broken
by Felix Hartmann 22 Nov '09

22 Nov '09

I am not sure if you are aware, that the overview map still is not correct (this causes on my compile of Asia large parts of the map to be invisible in Mapsource). Also for smaller maps it often seems to be too small. See the two following screenshots: 1. overview map of Asia missing in the middle (or is this a Mapsource problem with maps spanning too large areas?): 2. Overview map broken for a small testmap that I use as a legend. See the boundaries that are partly outside of the map area: The actual side of the white background seems correct, but moved. If I zoom in the boundary will dissapear outside of the white area.

2 3

Commit: r1402: If a polish map contains any background polygons, don't generate one.
by svn commit 22 Nov '09

22 Nov '09

Version 1402 was commited by markb on 2009-11-22 22:21:55 +0000 (Sun, 22 Nov 2009) If a polish map contains any background polygons, don't generate one. Normally, a polygon of type 0x4b is automatically generated to cover the map's background. For OSM maps that can't explicitly contain such a polygon, this is reasonable. Polish maps can contain polygons of type 0x4b. So if a Polish map does contain any polygons of type 0x4b, suppress the automatic generation of the background polygon.

1 0

Commit: r1401: Added RoundCoordsFilter to round lat/lon to nearest when shift > 0.
by svn commit 22 Nov '09

22 Nov '09

Version 1401 was commited by markb on 2009-11-22 22:21:51 +0000 (Sun, 22 Nov 2009) Added RoundCoordsFilter to round lat/lon to nearest when shift > 0. Also removes identical consecutive points - they will get removed later anyway but it's very easy to do here and it makes sense to remove them early to reduce the number of points needed to be processed by the following filters.

1 0

Commit: r1363: Merge the mapset branch back to trunk.
by svn commit 22 Nov '09

22 Nov '09

Version 1363 was commited by steve on 2009-11-09 10:42:25 +0000 (Mon, 09 Nov 2009) Merge the mapset branch back to trunk. Makes it possible to have maps with different family id's in the same gmapsupp.

3 3