May 2010 - mkgmap-dev - The mkgmap lists

Really Serious bug when not using --route
by Felix Hartmann 31 May '10

31 May '10

There is a serious bug that breaks routable maps when --route is NOT given. This bug will in future break routing on most GPS devices and is already inflicting Mapsource 6.16.1 and Basecamp 3. This means that also if you compile maps that are not routable, you have to pass the --route parameter. Else the GPS / Mapsource looks into an empty NOD table and may crash. This will happen as soon as you mix routable maps with the non routable mkgmap created maps. The problem is that Mapsource and the GPS search for 63440000.NOD data (63440000 as an example placeholder for the mapname). "Falagar", a developer at Garmin said to release a fix for this bug in Mapsource 6.16.2 however mentioned that this fix will not be carried on to GPS devices and will still mean a deterioration of overall routing. I'm not sure what the exact problem for this is (I just tried even very old mkgmap versions like 858 and also there the problem arises) but currently this means that --route should be the compulsory for all map creation, also not routable ones. If you have old maps (eg transparent contourline maps) that are troublesome to rebuilt, then opening with gpsmapedit, saving as mp and recompiling passing --route parameter is enough to solve the problem. I think that until the bug is found, mkgmap should adopt --route as standard, because it may happen that if users put an mkgmap created without --route onto their GPS besides other routable maps, these maps might impact autorouting for the other routable maps (except if "deactivated" on the GPS).

7 38

Build display::trunk #215 successful
by teamcity＠mkgmap.org.uk 31 May '10

31 May '10

Build display::trunk #215 successful Build results: http://teamcity.mkgmap.org.uk/viewLog.html?buildId=2707&buildTypeId=bt11 ============================================================================ Configure email notifications: http://teamcity.mkgmap.org.uk/profile.html?init=1&tab=userNotifications

1 0

Build display::trunk #214 failed (compilation failed)
by teamcity＠mkgmap.org.uk 31 May '10

31 May '10

Build display::trunk #214 failed (compilation failed) Agent: Iocaste Build results: http://teamcity.mkgmap.org.uk/viewLog.html?buildId=2703&buildTypeId=bt11 Compilation errors ================== /opt/TeamCity/buildAgent/work/89359763abd97e41/src/test/display/RgnDisplay.java:201: cannot find symbol symbol : method getBitPosition() location: class uk.me.parabola.imgfmt.app.BitReader while (br.getBitPosition() <= 8* bslen - ((extra ? 1:0) + xbase + ybase)) { ^ /opt/TeamCity/buildAgent/work/89359763abd97e41/src/test/display/RgnDisplay.java:202: cannot find symbol symbol : method getBitPosition() location: class uk.me.parabola.imgfmt.app.BitReader br.getBitPosition(); ^ /opt/TeamCity/buildAgent/work/89359763abd97e41/src/test/display/RgnDisplay.java:234: cannot find symbol symbol : method getBitPosition() location: class uk.me.parabola.imgfmt.app.BitReader int bleft = 8*bslen - br.getBitPosition(); ^ 3 errors Compile failed; see the compiler error output for details. ============================================================================ Configure email notifications: http://teamcity.mkgmap.org.uk/profile.html?init=1&tab=userNotifications

1 0

Commit: r1650: Code tidy.
by svn commit 31 May '10

31 May '10

Version 1650 was commited by steve on 2010-05-31 13:35:06 +0100 (Mon, 31 May 2010) Code tidy. Should not affect the working of mkgmap in any way.

1 0

Commit: r1649: Move the static version of hasExtendedType from MapElement
by svn commit 30 May '10

30 May '10

Version 1649 was commited by steve on 2010-05-30 12:12:40 +0100 (Sun, 30 May 2010) Move the static version of hasExtendedType from MapElement to MapObject, so we don't have calls from imgfmt to mkgmap.

1 0

How do Display & Find Towns tagged as a relation/multipolygon?
by Dave F. 30 May '10

30 May '10

Hi Using a Garmin 300 http://www.openstreetmap.org/?lat=51.121&lon=-2.741&zoom=14&layers=B000FTF This town doesn't have a POI node to tag the town's name but uses a multi polygon. Is there a way at present to: 1. display the residential boundary 2. display the town's name 3. Make it findable? Thanks for any help Cheers Dave F.

1 0

Umlauts and semicolons causing parsing errors?
by NopMap 29 May '10

29 May '10

Hi! A fellow mapper has encountered a problem that mkgmap throws error messages for rendering rules that have a semicolon or an umlaut in the value after switching to mkgmap 1625. The same ruleset did work with older versions. Is this a deliberate change or a bug? bye Nop -- View this message in context: http://gis.638310.n2.nabble.com/Umlauts-and-semicolons-causing-parsing-erro… Sent from the Mkgmap Development mailing list archive at Nabble.com.

2 3

Commit: r1648: Add historic=archaeological_site, historic=ruins, place=island, place=islet.
by svn commit 26 May '10

26 May '10

Version 1648 was commited by marko on 2010-05-26 09:58:58 +0100 (Wed, 26 May 2010) Add historic=archaeological_site, historic=ruins, place=island, place=islet.

1 0

Re: [mkgmap-dev] Maintaining generated sea polygons
by Minko 25 May '10

25 May '10

Hi, I don't know if this is the same problem as Nop described, but lately I found that on my map some sea areas were gone in the Netherlands: see http://img338.imageshack.us/img338/9992/errorcoastline.jpg On osm it looks ok: http://www.openstreetmap.org/?lat=52.817&lon=4.955&zoom=10&layers=B000FTF Im using the geofabrik abstract from europe to compile my benelux map, Any idea how to fix this? I tried another abstract (planet-benelux) but this gave the same results. Is it caused by the splitter? Is it an error in de osm data? In the mkgmap args i use generate-sea: no-mp,extend-sea-sectors,close-gaps=1000 and it never went wrong except for the last two weeks. Nop wrote: Hi! I have been playing around with generated sea polygons. The algorithm works remarkably well - but I have been experiencing trouble due to inconsistent use of natural=coastline in the data. There was an invalid use of natural=coastline in the planetfile, that caused a whole tile in the Alps to be flooded. So I tracked it down, fixed it and waited for the next planetfile. This time another tile near Berlin was flooded. I tracked it down, noted that another mapper had already fixed it and waited for the next planetfile. This time another tile south of Würzburg was flooded... - you note the pattern? :-) For three weeks I have been unable to grab a planetfile with correct coastline for central europe - they are broken at about the same speed we can fix them. So even though I was able to build a really nice map a while ago, all update attempts were broken. Therefore my question: Would it be possible to save the generated sea polygons to disk in osm format so an intact set of polygons can be re-used with future osm data? That way it could be ensured that future updates will have the same, correct sea polygons and not be randomly broken by temporary inconsistencies in the osm data. Storing the image files and using them as a seperate map layer is not a solution as older Garmin devices are really cumbersome with layers or cannot handle multiple layers at all - and the map is for an older device. Any ideas? Nop -- View this message in context: http://gis.638310.n2.nabble.com/Maintaining-generated-sea-polygons-tp508286… Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list mkgmap-dev(a)lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

6 11

Maintaining generated sea polygons
by NopMap 25 May '10

25 May '10

Hi! I have been playing around with generated sea polygons. The algorithm works remarkably well - but I have been experiencing trouble due to inconsistent use of natural=coastline in the data. There was an invalid use of natural=coastline in the planetfile, that caused a whole tile in the Alps to be flooded. So I tracked it down, fixed it and waited for the next planetfile. This time another tile near Berlin was flooded. I tracked it down, noted that another mapper had already fixed it and waited for the next planetfile. This time another tile south of Würzburg was flooded... - you note the pattern? :-) For three weeks I have been unable to grab a planetfile with correct coastline for central europe - they are broken at about the same speed we can fix them. So even though I was able to build a really nice map a while ago, all update attempts were broken. Therefore my question: Would it be possible to save the generated sea polygons to disk in osm format so an intact set of polygons can be re-used with future osm data? That way it could be ensured that future updates will have the same, correct sea polygons and not be randomly broken by temporary inconsistencies in the osm data. Storing the image files and using them as a seperate map layer is not a solution as older Garmin devices are really cumbersome with layers or cannot handle multiple layers at all - and the map is for an older device. Any ideas? Nop -- View this message in context: http://gis.638310.n2.nabble.com/Maintaining-generated-sea-polygons-tp508286… Sent from the Mkgmap Development mailing list archive at Nabble.com.

6 7