- mkgmap-dev - The mkgmap lists

[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

Address search icon behavior varies in some gps units
by maning sambale 17 Mar '10

17 Mar '10

Hi, Just an FYI to the great mkgmap devs. :) This feedback came from someone using my OSM-PH garmin maps. In Garmin Nuvi 855 when you click the Address icon to search an address, the popup message "No map data found." will immediately appear. In other Garmin units like 205w and 265w you can enter the city, street and house number. Some addresses are already working when you search for it. Provided the point in the map contains keys for address search such addr:<category here> you can search for it. It's working in 205w. In Garmin Nuvi 855 i don't know what's the problem. It won't let me search for an address. It could be that firmware for Garmin Nuvi 8 series is looking for a starting index, but i'm not sure about this. I'm already using the latest firmware. I just updated last week. The problem is the same with the previous and latest firmware. -- 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

Re: [mkgmap-dev] mkgmap gets stuck on Kosovo
by Felix Hartmann 16 Mar '10

16 Mar '10

On 05.03.2010 22:03, Felix Hartmann wrote: > > > On 05.03.2010 22:00, Mark Burton wrote: >> Felix, >> >>> The very first time it got stuck about 6 hours. Normal style >>> finishes in >>> 30 seconds. Actually I get stuck too now on Europe.... >>> >>> There must be some serious bug or new kind of data people are >>> writing in >>> OSM. >> In your style, do you generate multiple routable ways for each road? >> >> Mark > Not for each, but for many (basically if any extended attribute like a > route, mtb:scale, incline, oneway, .... exist). > > You can download my style either as 7zip (lzma) from here: > http://svn.origo.ethz.ch/dump/openmtbmap/latest.tar.gz > Look at it here: http://svn.origo.ethz.ch/wsvn/openmtbmap/ > or checkout from SVN: https://svn.origo.ethz.ch/openmtbmap/ > Any news on solving this bug. I get stuck now on more and more countries. For my style, this is getting really serious trouble (basically unable to compile 1/10 countries, meaning I can't update my maps anymore as it gets stuck)

2 12

Commit: r1605: Treat a label with empty text the same way as one with null text.
by svn commit 16 Mar '10

16 Mar '10

Version 1605 was commited by steve on 2010-03-16 09:42:50 +0000 (Tue, 16 Mar 2010) Treat a label with empty text the same way as one with null text. It should have offset 0 in the LBL section.

1 0

Commit: r1604: I have seen that on some occasions
by svn commit 16 Mar '10

16 Mar '10

Version 1604 was commited by steve on 2010-03-16 09:39:56 +0000 (Tue, 16 Mar 2010) I have seen that on some occasions the uninstaller does not get remove at uninstall and that moving it to be the last file removed improves the behavior. - Nakor

1 0