October 2011 - mkgmap-dev - The mkgmap lists

Area to small to split and subdivision shift errors
by Felix Hartmann 06 Oct '11

06 Oct '11

Could those to errors be degraded to notice level from error level? They are not really significant and it's not nice that in order to spot really important errors, when you produce many maps, or a map say of Europe, you have to sift through all these rather unimportant messages.... I want to show errors that really havoc (like the current java lang error where full tiles will be missing), but do not have rather everyday unimportant errors in my logs.

2 1

OSM maps on the new eTrex 30
by Frank Fesevur 06 Oct '11

06 Oct '11

Hi, Does anybody already has any experience with a mkgmap generated map on the brand new Garmin eTrex 20 or 30? I know these models are available for just a couple of days now, but I'm seriously considering buying a eTrex 30 any time soon. But I only buy it when the OSM based maps work on them. Maybe I can take a gmapsupp.img with me to the shop and try myself before I buy it, but if anyone already has any experience I would really like to know. Regards, Frank

6 17

splitter r-180
by steve sgalowski 05 Oct '11

05 Oct '11

attempting to split up daily planet files on australia into smaller pieces , but the program only reads 17,5000 nodes and then drops dead . Stephen

3 3

Differences between gmapsupp files
by Carlos Dávila 04 Oct '11

04 Oct '11

I have compared with GMapTool gmapsupp.img files generated by mkgmap in a single step [1] along with all tiles img's, overview and index or in a separate step [2+3] just joining the img's. I can see a couple of differences: a) Single step creation assigns last map in args file as mapset name whereas two steps creation assigns a default "OSM street map" name. In the first case, wouldn't it be better to give mapset a name representing all the map, such as series-name or family-name. Regarding "OSM street map" I find "OpenStreetMap" would be more appropriate, don't you? b) Map generated in two steps lacks SRT map and subfile. I didn't find many information about the purpose of the SRT file. Would it make any difference on the functionality of the gmapsupp having no SRT? [1] java -Xmx600m -ea -jar mkgmap.jar --generate-sea=polygons,extend-sea-sectors --route --latin1 --code-page=1252 --gmapsupp --series-name="OSM-Portugal" --overview-mapname=55220000 --index --road-name-pois --ignore-maxspeeds --remove-short-arcs --merge-lines --add-pois-to-areas --adjust-turn-headings --report-similar-arcs --link-pois-to-ways --location-autofill=bounds --drive-on-right --check-roundabouts --check-roundabout-flares --style=mio typ/PORTU-22.TYP -c portugal.args [2] java -Xmx600m -ea -jar mkgmap.jar --generate-sea=polygons,extend-sea-sectors --route --latin1 --code-page=1252 --series-name="OSM-Portugal" --overview-mapname=55220000 --index --road-name-pois --ignore-maxspeeds --remove-short-arcs --merge-lines --add-pois-to-areas --adjust-turn-headings --report-similar-arcs --link-pois-to-ways --location-autofill=bounds --drive-on-right --check-roundabouts --check-roundabout-flares --style=mio typ/PORTU-22.TYP -c portugal.args [3] java -Xmx1000m -ea -jar mkgmap.jar --gmapsupp --country-name=Portugal --country-abbr=POR --area-name=Portugal --family-name="OpenStreetMap Portugal" --family-id=22 --product-id=1 --series-name="OSM-Portugal" --index PORTU-22.TYP 5522*.img

2 2

Commit: r2045: Merge the index-memory branch.
by svn commit 04 Oct '11

04 Oct '11

Version 2045 was commited by steve on 2011-10-03 16:03:57 +0100 (Mon, 03 Oct 2011) Merge the index-memory branch. -Vastly improves the memory usage when creating and index. -If the index creation fails then the index output file is not written. Requires less than half the amount of memory than the old code, and it is quicker too as a nice side effect.

3 2

Bug introduced with rev 2038 making mkgmap crash on certain tiles.
by Felix Hartmann 04 Oct '11

04 Oct '11

I have never seen this bug before, it appears since mkgmap rev 2038. Rev 2037 was still fine. It does not happen very often, just on a few tiles. Also without my style-file it does not happen... So there seems to be some serious problem related to those decimal numbers.... I'll try to find out which line in my style-file is responsible for this crash... so far the error log: java.lang.NumberFormatException at java.math.BigDecimal.<init>(Unknown Source) at java.math.BigDecimal.<init>(Unknown Source) at uk.me.parabola.mkgmap.osmstyle.eval.ValueWithUnit.<init>(ValueWithUnit.java:47) at uk.me.parabola.mkgmap.osmstyle.eval.NumericOp.eval(NumericOp.java:51) at uk.me.parabola.mkgmap.osmstyle.eval.AndOp.eval(AndOp.java:34) at uk.me.parabola.mkgmap.osmstyle.eval.LinkedOp.eval(LinkedOp.java:55) at uk.me.parabola.mkgmap.osmstyle.ActionRule.resolveType(ActionRule.java:59) at uk.me.parabola.mkgmap.osmstyle.RuleSet.resolveType(RuleSet.java:79) at uk.me.parabola.mkgmap.osmstyle.StyledConverter.convertNode(StyledConverter.java:349) at uk.me.parabola.mkgmap.reader.osm.ElementSaver.convert(ElementSaver.java:234) at uk.me.parabola.mkgmap.reader.osm.bin.OsmBinMapDataSource.load(OsmBinMapDataSource.java:72) at uk.me.parabola.mkgmap.main.MapMaker.loadFromFile(MapMaker.java:148) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:58) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:222) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:219) at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source)

2 2

Commit: r2046: Fix problem that meant that string temporary file
by svn commit 04 Oct '11

04 Oct '11

Version 2046 was commited by steve on 2011-10-04 15:06:47 +0100 (Tue, 04 Oct 2011) Fix problem that meant that string temporary file sometimes was not deleted on Windows. It was the same as a previous problem, if you memory map a file then you can't delete it until the mapping is removed and there is no portable way of doing that. It gets removed when its buffer is garbage collected.

1 0

POI address to points with 3-byte TYP IDs
by Bernhard Moser 03 Oct '11

03 Oct '11

Hi, Does mkgmap add POI information (street, house number, region, phone, etc.) also to points with 3-byte TYP IDs with format 0x1xxss (e.g. 0x11501) or is this only done for IDs with format 0x0xxss (e.g. 0x01, 0x2e; with or without subtype) ? I want to assign different Garmin Typ IDs to POIs of same category (e.g. Shopping - Grocery) to separate for instance between supermarket, bakery and butcher. Goal is to have several icons for each shop type but all these shops should be searchable, found in category 'Shopping - Grocery'. Therefore I need several Garmin Typ IDs which are within one category. For above example there exist the following TYP IDs 0x2e02, 0x10f02 and 0x20f02 to which different icons can be assigned and which can be found in 'Shopping - Grocery'. In Mapsource/Basecamp and on the Oregon 450t all icons are shown as expected. But only the icon with TYP ID 0x2e02 has added address and region (which is done by locator-autofill I think). To the other TYP IDs (> 0x100ss) no locator information is assigned. I've already heard about Garmin TYP ID ranges where no 'popup' information is shown... But in this case I use TYP IDs which are used by Garmin City Navigator 2012 and on this map this POIs have address and region. Any reason? Best regards, Berny

3 2

Commit: r2042: Correct the sorting of streets in mdr20 when a city
by svn commit 02 Oct '11

02 Oct '11

Version 2042 was commited by steve on 2011-09-30 14:22:50 +0100 (Fri, 30 Sep 2011) Correct the sorting of streets in mdr20 when a city is split over more than one tile. The valid sorting takes a lot more memory. If this is a problem the please use the index-memory branch, until that is merged.

2 1