March 2010 - mkgmap-dev - The mkgmap lists

understanding mkgmap logs
by maning sambale 19 Mar '10

19 Mar '10

Hi, Thanks to charlie I activated logging in my map compilation and it sure helps in fixing routing issues! I already found and fixed a few oneways coming from nowhere Several reports I don't understand: 2010/03/18 20:31:26 WARNING (StyledConverter): philippines.osm: Motorway exit null (http://www.openstreetmap.org/?mlat=7.07588&mlon=125.62656&zoom=17) has no motorway! (either make the exit share a node with the motorway or specify the motorway ref with a exit:road_ref tag) 2010/03/18 20:31:26 WARNING (StyledConverter): philippines.osm: Motorway exit closed subdivision gate (http://www.openstreetmap.org/?mlat=14.13477&mlon=120.97857&zoom=17) has no motorway! (either make the exit share a node with the motorway or specify the motorway ref with a exit:road_ref tag) In my style I assigned barrier=gate as a highway exit: barrier=gate [0x2001 resolution 24] Full log is here: http://dl.dropbox.com/u/607635/osm-ph_gps_maps/latest/mkgmap.log.0.txt -- cheers, maning ------------------------------------------------------ "Freedom is still the most radical idea of all" -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ ------------------------------------------------------

2 2

[PATCH v1] Multipolygon: Allow nested inner polygons
by WanMil 19 Mar '10

19 Mar '10

I have found that some multipolygons use nested inner polygons. Example: * A forest (outer) with a lake (inner) that has an island (inner) which is not a forest. (example: http://www.openstreetmap.org/browse/relation/331402) By definition of the multipolygon relation (http://wiki.openstreetmap.org/wiki/Relation:multipolygon) one has to create two mps. But I see that it is a nice simplification lots of mappers are using. Attached patch handles this situation. The inner and outer roles are now used as follows: * the outmost polygon must have role=outer (or role=<empty>) * all outmost polygons with role=inner are not used (a warning is issued) * all inside polygons with role=inner use their own tagging * all inside polygons with role=outer use the mp tagging if available or their own tagging if the mp is not tagged * all inside polygons with role=<empty> are categorized automatically as outer/inner depending on the nest level * all inside polygons with role=outer without a direct ambient inner polygon are dropped with a warning message (outer in outer polygon) Most of the renderers do not support inner in inner polygons but I think it is a very reasonable extension of the multipolygon handling. This patch also improves the error messages. I haven't seen any more "are not processed due to an unknown reason" messages and I look forward that the community will also not be able to generate any more ... ;-) WanMil

7 23

[PATCH v3] - Code around highway shield crap when sorting labels
by Mark Burton 18 Mar '10

18 Mar '10

v3 - now works harder to clean up road names for use in MDR file - not sure if this will have a beneficial effect but it could possibly fix the issue recently reported by Felix. Motorways are still not showing up. ------- v2 - remove more duplicate labels that only differ in letter case - remove leading spaces from labels even if they start with a Garmin code. Still something wrong with motorway names because on the UK map, only the M74 appears in the mapsource road names - all other motorways are missing - very odd. ------- This patch codes around the problems introduced by highway shields with regard to the sorted roads: 1 - the sort order should now be much improved 2 - no duplicate symbols (shield version + non-shield version) It also includes a fix to the label reading code so that labels with a highway shield prefix are read in correctly when generating the MDR file. For me, in mapsource, road search for roads with highway shields now works apart from motorways which don't seem to searchable - perhaps that's deliberate on Garmin's part? All feedback appreciated. Mark

2 2

Broken Routes based on mkgmap map due to "functional characters" inside name
by Felix Hartmann 18 Mar '10

18 Mar '10

Hi, I just got this comment yesterday via my homepage. Seemingly mkgmap in some circumstances puts ENQ - functional characters into the name of streets (when adding the name from a route relation). This causesMapsource not being able to reopen a saved route, nor the route working correctly on GPS. The functional are not displayed inside the tooltip, but visible when opening a (.gdb) route inside a text editor). My style-files are accessible here (Web-SVN or SVN): http://openmtbmap.origo.ethz.ch/wiki/development See the original comment I got in German below: Comment: Hallo, ich schon wieder!! Bei mir ist folgendes Problem aufgetreten: Ich habe Routen mit Mapsource auf der NRW- (openmtbmap – nordrhein-westfalen.7z.zip)oder Holland-Karte (openmtbmap – Netherlands)erstellt, konnte die jedoch teilweise nicht vom PC auf's Nüvi übertragen. Dank netter Menschen im Garmin-Forum stellte sich als Ursache heraus, dass bei den problematischen Routen an einer oder an mehreren Stellen in der Datei (als GPX mit MS gespeichert (lassen sich aber mit MS nicht wieder ööffnen) und mit einem Editor betrachtet) ENQ - Steuerzeichens enthalten waren. Die entsprechenden Zeilen sehen so aus; Nrw Nrw Radverkehrsnetz Nrw, Kreis Borken Lcn Cw Nrw Nrw Radverkehrsnetz Nrw, Kreis Borken Lcn Cw oder Rom Rom Via Romana Rcn Trk Rom Rom Via Romana Rcn Trk Das markante ist also, dass das erste Wort des Textes mit diesem ENQ - Steuerzeichen wiederholt wird. Da das doch die Infos aus den Karten sind, frage ich mich, ob die Daten evtl. so aus den Karten kommen. Die Abspeicherung der Route als GPX und die Öffnung mit dem Editor können nicht die Ursache sein, da auch das Nüvi 550 solche Routen nicht mal als Datei (geschweige denn als Route verareitet) annimmt. Wenn ich diese ENQ's entferne und die Datei mit MS öffne, dann ist wieder alles ok und das Nüvi nimmt sie an.

3 2

[PATCH v2] - Code around highway shield crap when sorting labels
by Mark Burton 18 Mar '10

18 Mar '10

v2 - remove more duplicate labels that only differ in letter case - remove leading spaces from labels even if they start with a Garmin code. Still something wrong with motorway names because on the UK map, only the M74 appears in the mapsource road names - all other motorways are missing - very odd. ------- This patch codes around the problems introduced by highway shields with regard to the sorted roads: 1 - the sort order should now be much improved 2 - no duplicate symbols (shield version + non-shield version) It also includes a fix to the label reading code so that labels with a highway shield prefix are read in correctly when generating the MDR file. For me, in mapsource, road search for roads with highway shields now works apart from motorways which don't seem to searchable - perhaps that's deliberate on Garmin's part? All feedback appreciated. Mark

1 0

error compiling the map
by maning sambale 18 Mar '10

18 Mar '10

I got this error recently: time java -Xmx1512m -jar mkgmap.jar --read-config=args.list philippines.osm java.lang.NullPointerException at uk.me.parabola.mkgmap.osmstyle.RuleFileReader.isIndexable(RuleFileReader.java:234) at uk.me.parabola.mkgmap.osmstyle.RuleFileReader.isSolved(RuleFileReader.java:242) at uk.me.parabola.mkgmap.osmstyle.RuleFileReader.isFinished(RuleFileReader.java:254) at uk.me.parabola.mkgmap.osmstyle.RuleFileReader.rearrangeExpression(RuleFileReader.java:134) at uk.me.parabola.mkgmap.osmstyle.RuleFileReader.saveRule(RuleFileReader.java:115) at uk.me.parabola.mkgmap.osmstyle.RuleFileReader.load(RuleFileReader.java:94) at uk.me.parabola.mkgmap.osmstyle.RuleFileReader.load(RuleFileReader.java:70) at uk.me.parabola.mkgmap.osmstyle.StyleImpl.readRules(StyleImpl.java:252) at uk.me.parabola.mkgmap.osmstyle.StyleImpl.<init>(StyleImpl.java:138) at uk.me.parabola.mkgmap.reader.osm.xml.Osm5MapDataSource.createStyler(Osm5MapDataSource.java:120) at uk.me.parabola.mkgmap.reader.osm.xml.Osm5MapDataSource.load(Osm5MapDataSource.java:80) at uk.me.parabola.mkgmap.main.MapMaker.loadFromFile(MapMaker.java:148) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:56) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:189) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:186) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:619) my args.list code-page=1252 ea tdbfile latin1 country-abbr=PHI country-name=PHILIPPINES remove-short-arcs=5 route road-name-pois add-pois-to-areas family-id=639 family-name=OSM_PHIL overview-mapname=40000001 series-name=OSM_PHIL description=OSM_PHIL style-file=/home/maning/Downloads/osm/routable_garmin/svn/styles/osm-ph generate-sea=polygons index adjust-turn-headings mkgmap version 1598 -- cheers, maning ------------------------------------------------------ "Freedom is still the most radical idea of all" -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ ------------------------------------------------------

2 3

[PATCH v1] - Code around highway shield crap when sorting labels
by Mark Burton 18 Mar '10

18 Mar '10

This patch codes around the problems introduced by highway shields with regard to the sorted roads: 1 - the sort order should now be much improved 2 - no duplicate symbols (shield version + non-shield version) It also includes a fix to the label reading code so that labels with a highway shield prefix are read in correctly when generating the MDR file. For me, in mapsource, road search for roads with highway shields now works apart from motorways which don't seem to searchable - perhaps that's deliberate on Garmin's part? All feedback appreciated. Mark

1 0

Commit: r1607: I have found that some multipolygons use nested inner polygons.
by svn commit 17 Mar '10

17 Mar '10

Version 1607 was commited by steve on 2010-03-17 08:35:24 +0000 (Wed, 17 Mar 2010) I have found that some multipolygons use nested inner polygons. Example: * A forest (outer) with a lake (inner) that has an island (inner) which is not a forest. (example: http://www.openstreetmap.org/browse/relation/331402) By definition of the multipolygon relation (http://wiki.openstreetmap.org/wiki/Relation:multipolygon) one has to create two mps. But I see that it is a nice simplification lots of mappers are using. Attached patch handles this situation. The inner and outer roles are now used as follows: * the outmost polygon must have role=outer (or role=<empty>) * all outmost polygons with role=inner are not used (a warning is issued) * all inside polygons with role=inner use their own tagging * all inside polygons with role=outer use the mp tagging if available or their own tagging if the mp is not tagged * all inside polygons with role=<empty> are categorized automatically as outer/inner depending on the nest level * all inside polygons with role=outer without a direct ambient inner polygon are dropped with a warning message (outer in outer polygon) Most of the renderers do not support inner in inner polygons but I think it is a very reasonable extension of the multipolygon handling. This patch also improves the error messages. I haven't seen any more "are not processed due to an unknown reason" messages and I look forward that the community will also not be able to generate any more ... ;-) v2+3: improves the handling of roles and warning messages in multipolygon. - A reasonable warning message for nested outer and nested inner polygons is given - nested inner polygons are processed anyhow - WanMil

1 0

Commit: r1606: Translate amenity=supermarket at resolution 20
by svn commit 17 Mar '10

17 Mar '10

Version 1606 was commited by marko on 2010-03-17 08:21:10 +0000 (Wed, 17 Mar 2010) Translate amenity=supermarket at resolution 20 and note that it is superceded by shop=supermarket or landuse=retail. Pointed out by Carlos D?\195?\161vila.

1 0

supermarket in default style
by Carlos Dávila 17 Mar '10

17 Mar '10

I think I found a bug in default polygons style (thanks to some comments from Daniela). Currently we have amenity=supermarket [0x08 resolution 20] in the default polygons style, but according to wiki [1], supermarket value is used for shop key. I searched spain.osm for amenity=supermarket and didn't find any, but 1298 shop=supermarket, so I guess this key&value pair must not have been very used in other places. As we also have shop=* [0x08 resolution 20] in default style, I propose to delete the amenity=supermarket line to avoid confusion. [1] http://wiki.openstreetmap.org/wiki/Map_Features#Shop Carlos

2 1