December 2014 - mkgmap-dev - The mkgmap lists

nsis & typ file name
by nwillink 05 Dec '14

05 Dec '14

Hi Have noticed that mkgmap creates a temporary typ file by placing an x in front of the filename - ie original mytyp.typ becomes xmytyp.typ (if I write protect the TYP file directory it spits out:Could not write temporary TYP file: K:\dum\xmytyp.typ) this is not a problem itself but in the NSIS script it still refers to the temporary file. in the .nsi script I get : File "xmytyp.typ" and not : File "mytyp.typ" Any ideas? r Nick I use java -Xmx1024m -ea -jar C:\A_UPL2~1\MKGMAP~1\MK90EB~1\mkgmap.jar --mapname=78200494 --family-id=6228 K:\dum\mytyp.typ --nsis c:\map.osm -- View this message in context: http://gis.19327.n5.nabble.com/nsis-typ-file-name-tp5826319.html Sent from the Mkgmap Development mailing list archive at Nabble.com.

2 4

[Patch v5] drive-on-left/drive-on-right handling
by Gerd Petermann 05 Dec '14

05 Dec '14

Hi all, attached is v5 of the patch, only change to v4 is corrected documentation of the options. Please test this with your data, if I hear no complains I'll commit it next monday. Note that the patch will issue an error message for each tile containing both drive-on-left and drive-on-right roads: Time started: Thu Dec 04 11:12:38 CET 2014 SCHWERWIEGEND (StyledConverter): e:\osm_out_work\africa\20130428_142650\63240015.o5m: Attention: Tile contains both drive-on-left (2963) and drive-on-right roads (27376) SCHWERWIEGEND (StyledConverter): e:\osm_out_work\africa\20130428_142650\63240022.o5m: Attention: Tile contains both drive-on-left (2029) and drive-on-right roads (31251) SCHWERWIEGEND (StyledConverter): e:\osm_out_work\africa\20130428_142650\63240023.o5m: Attention: Tile contains both drive-on-left (2820) and drive-on-right roads (20553) SCHWERWIEGEND (StyledConverter): e:\osm_out_work\africa\20130428_142650\63240025.o5m: Attention: Tile contains both drive-on-left (33305) and drive-on-right roads (39882) ... Let me know when this causes trouble! A compiled binary based on r3361 is here: http://files.mkgmap.org.uk/download/235/mkgmap.jar Gerd

3 4

Commit: r3363: Change severity to warning for removed way that is part of valid restriction relation.
by svn commit 05 Dec '14

05 Dec '14

Version mkgmap-r3363 was committed by gerd on Fri, 05 Dec 2014 Change severity to warning for removed way that is part of valid restriction relation. The way might be very short and leading to nowhere, in this case it is okay to remove the way and later ignore the restriction.

1 0

Occasional header corruption in gmapsupp.img
by franco_bez 04 Dec '14

04 Dec '14

Hi all, once again I stumbled over a really weird problem: In rare cases mkgmap produces a gmasupp.img that shows up as "Map data (c) OpenSt" in the list of maps on my Oregon 550. Screenshots: <http://gis.19327.n5.nabble.com/file/n5825759/bad_01.png> <http://gis.19327.n5.nabble.com/file/n5825759/bad03.png> <http://gis.19327.n5.nabble.com/file/n5825759/bad04.png> <http://gis.19327.n5.nabble.com/file/n5825759/good_01.png> <http://gis.19327.n5.nabble.com/file/n5825759/good03.png> <http://gis.19327.n5.nabble.com/file/n5825759/good04.png> There is no error message or warning when building the gmapsupp.img, I observe this problem for some 4 month now and I can 100% reproduce the bug. It seems to be triggered by the OSM-inputdata although the OSM-data itself is OK. The problem occurred on a DACH-extract with my bikeroute-highlights-overlay style a few months ago, now I have it with a ITALY-extract and my housenumbers-overlay style. Usually I build 6 different gamapsupp.img files for 6 different styles from the same tiles. Only one of them, if any, has the buggy header. The problem usually disappears after an update of the OSM-data, just to reappear a few days or weeks later. I kept 2 versions of the ITALY-extract for reference and with those I can 100% reproduce a faulty gmapsupp.img. I often update the versions of splitter and mkgmap I use for building the maps. mkgmap-r3356 and splitter-r414 still produce the same bug. The problem assembling a test-case is that the ITALY-extract has a size of 1.2 GB . When I remove just one tile from the split extract the gmapsupp.img is OK. I cannot produce a small testcase. I uploaded a sample of a gmapsupp.img with the bug, and one that is error free. http://files.mkgmap.org.uk/download/233/maps.tgz Ciao, Franco -- View this message in context: http://gis.19327.n5.nabble.com/Occasional-header-corruption-in-gmapsupp-img… Sent from the Mkgmap Development mailing list archive at Nabble.com.

2 6

Commit: r3362: Fix size calculation for gmapsupp.
by svn commit 04 Dec '14

04 Dec '14

Version mkgmap-r3362 was committed by steve on Thu, 04 Dec 2014 Fix size calculation for gmapsupp. This would lead to the MPS file appearing not to be present and so the names would show differently. TODO: It will still be incorrect for unicode files.

1 0

Commit: r3361: fix typo GERMAYN -> GERMANY
by svn commit 04 Dec '14

04 Dec '14

Version mkgmap-r3361 was committed by gerd on Thu, 04 Dec 2014 fix typo GERMAYN -> GERMANY

1 0

Commit: r3360: revert unintended change of build.xml
by svn commit 04 Dec '14

04 Dec '14

Version mkgmap-r3360 was committed by gerd on Thu, 04 Dec 2014 revert unintended change of build.xml

1 0

Commit: r3359: evaluate-associatedStreet-rel-v2.patch: improve house number evaluation
by svn commit 04 Dec '14

04 Dec '14

Version mkgmap-r3359 was committed by gerd on Thu, 04 Dec 2014 evaluate-associatedStreet-rel-v2.patch: improve house number evaluation The data in type=associatedStreet and type=street relations is used to fill missing street name info.

1 0

[Patch v4] drive-on-left/drive-on-right handling
by Gerd Petermann 03 Dec '14

03 Dec '14

Hi all, attached is v4 of the patch. The drive-on parameter now accepts the following values: left|right|detect|detect,left|detect,right - detect is equal to detect,right - with detect all roads are counted to find out whether the map is a drive-on-left or drive-on-right map - if the detection doesn't return a clear result, the 2nd option is used - the polish reader only checks the "LeftSideTraffic" string, it doesn't count anything (for now) @Steve, WanMil: I've added methods getDriveOnLeft() to MapperBasedMapDataSource and use it in MapBuilder before a TREFile or NODFile is written to configure the corresponding flags. Classes that are able to detect the dr I think this is a bit cleaner compared to v3 and to trunk.

2 1

[Patch v3] drive-on-left/drive-on-right handling
by Gerd Petermann 02 Dec '14

02 Dec '14

Hi all, attached is v3 of the patch. I think we should finish this before we start with the coding for the non-rectangular tiles support. 1) I've tried to make sure that the flags in TRE and NOD are set to equal values. 2) The options --drive-on-left and --drive-on-right are deprecated but still evaluated, for now a warning is printed when they are used. The new option --drive-on=detect|right|left should be used instead. The value detect enables a rather complex (but not CPU-intensive) algo: 1) For each roundabout it checks if the country is known and -- if so -- if the country is a drive-on-left country. 2) If the number of "dol" roundabouts is larger than the rest, the internal drive-on switch is set to "left", similar the internal drive-on switch is set to "right" if the number of "dor" roundabouts is larger than the rest. This works only if either a complete bounds file is used or the default country is set with --country-abbr or --country-name. 3) If option --check-roundabouts is used and the internal drive-on switch is still "detect", than the first found roundabout is used to set the internal drive--on switch. 4) Finally, If the internal drive-on switch is "left", the flags in the headers are set to 1. 5) The polish fomat reader now recognizes the line LeftSideTraffic=Y in the mp file. 6) If the user specifies --drive-on=left, both header flags are set to 1, no matter what roundabouts are found. @Steve, WanMil: I've added a ThreadLocal<boolean> to TREHeader similar to that in NODHeader, but I think it would be better to store that info only once for each thread, I just don't know where, maybe MapMaker? Besides that I am not sure how this works when we write two different TREHeader files in one thread (one for the overview map data ovm_*.img) (well, the flag in these files is ignored anyway) Please suggest a better solution. Gerd

5 11