December 2016 - mkgmap-dev - The mkgmap lists

Commit r3733: use Int2ObjectOpenHashMap instead of HashMap to avoid random error in implicit calls of Integer.valueOf() which is probably caused by a JIT error in recent JRE versions.
by svn commit 19 Dec '16

19 Dec '16

Version mkgmap-r3733 was committed by gerd on Mon, 19 Dec 2016 use Int2ObjectOpenHashMap instead of HashMap to avoid random error in implicit calls of Integer.valueOf() which is probably caused by a JIT error in recent JRE versions. See also http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2016q4/025329.html http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3733

1 0

Commit r3732: simplify o5m format reader, no functional change
by svn commit 19 Dec '16

19 Dec '16

Version mkgmap-r3732 was committed by gerd on Mon, 19 Dec 2016 simplify o5m format reader, no functional change http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3732

1 0

mkgmap option product-version and gmapsupp format
by Patrik Brunner 18 Dec '16

18 Dec '16

Steve, as already announced: with all the intensive testing regarding unicode, gmap and others I found following in my opinion strange behaviour in relation to gmapsupp format: * my mkgmap call for gmapsupp creation contains the option '--product-version="1612"' * when checking the created gmapsupp.img with GMapTool, the heades does contain only 'v 0.00' * when checking the gmapsupp.img via BaseCamp while the GPS is connected the version column also shows 0.00 * the detailed output of GMapTool does not contain the string "1612" at all This raises my concern about product-version not properly handled in the gmapsupp conversion. Yes, I know, a gmapsupp.img may contain more than only one product/family/map... But as mkgmap creates a gmapsupp.img for one product/family only per run it might be worth writing the version info properly into the header ? .... other maps (official ones) seem to propagate the release information into that header field. I'm not completely sure if above assumptions are correct or if I missed something. Sorry for bringing up another issue.... ;-) And thanks for looking at it. Cheers Patrik

2 2

Re: [mkgmap-dev] Commit r3730: Merge file-encoding branch
by Mike Baggaley 18 Dec '16

18 Dec '16

Hi Steve, since including this change, my copyright file fails to be read. This appears to be because it is now expected to be in utf-8 format - mine is in ansii format. I have rewritten my copyright file to be in utf-8 and it now works again, however, the documentation does not say that it needs to be utf-8 and the error message does not give the reason. I discovered the reason by looking at the code. I suggest that this is less than ideal. Is there some reason why an ansi formatted file (the default file encoding on Windows) can't be handled? My license file is ansi and that loads ok. Regards, Mike

1 0

Adding the gmapi format.
by Steve Ratcliffe 18 Dec '16

18 Dec '16

Hi Thought I would start a new thread for the new options. To test, download the latest gmapi branch build from the bottom of the mkgmap download page. There is a new option --gmapi which you use just like you would use --gmapsupp. It creates a directory called osmmap.gmapi by default. I've compared to the result of MapConverter but have not otherwise tested it. It should deal with the index, TYP files etc. ..Steve

5 23

Commit r3731: Implement a new map output format "gmapi"
by svn commit 18 Dec '16

18 Dec '16

Version mkgmap-r3731 was committed by steve on Sun, 18 Dec 2016 Implement a new map output format "gmapi" When the --gmapi option is given then the map will be created in a directory named after the family name with an extension .gmap This format is used to install maps on a Mac. As with the --gmapsupp option, you can start with a set of .img files that where created in a previous mkgmap run if you wish, as well as in one step from the source OSM .pbf, .osm.gz etc files. http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3731

1 0

mkgmap: problems with encoding file used with option --license-file
by Patrik Brunner 18 Dec '16

18 Dec '16

Hello together, I'm using makemap (r3696) on Windows (non UTF-8 locale) and on Linux (UTF-8 locale) and got very strange and platform dependant behaviour. So I started to use the option -Dfile.encoding=utf-8 in the java call of mkgmap to have at least the same, still strange and different behaviour on both platforms. Here the facts: * I have special characters (Latin1) in the license file: äöüéè ... * If I build a unicode map and the license file is properly encoded in Unicode, Basecamp shows at the end scrambled characters * I'm able to get a unicode map with correct license info (no scrambled chars) only on Windows (non-utf8 environment) without calling mkgmap with -Dfile.encoding=utf-8 and some additional cheats * If I use mkgmap to create a gmapsupp.img it again looks different, bit better but not good. I know these facts are a bit unspecific, but I've really tested out quite a lot and no combination / tries did help to solve the problems. And before investing even more time and get completely lost I'll ask for help. Therefore: did I miss something essential or are the parameters --license-file and --copyright-file (I use the same file for both parameters) handled specially/different than other source files for mkgmap (no/different encoding support ?). We never had any problems with utf8 encoded style files or typ source files, all went always very smooth as long as everything was utf-8...but with the license files I got stuck now. Thanks in advance for hints / solutions / confirmations. Cheers Patrik

2 39

typ file and address search failure with contours
by Enrico Liboni 17 Dec '16

17 Dec '16

Folks, I had a weird problem I just sorted out - it was known that the position of the TYP file on command line may have some influence, I remember I read somewhere it is better to place it at the end as last argument. What is weird is something happen among r3642 and r3695 which changed the behavior. I used the following command since years: java -Xmx2000M -jar ./mkgmap/mkgmap.jar --max-jobs --latin1 --output-dir="./img"/ \ --family-id=10030 --product-id=1 --route --remove-short-arcs --bounds=bounds.zip \ --precomp-sea=sea.zip --location-autofill=is_in,nearest --draw-priority=20 --index --housenumbers --gmapsupp *./typ/gspeed.typ* ./work/7311*osm.pbf \ --family-id=10031 --product-id=1 --draw-priority=10000 --transparent *./typ/gspeed.typ *./contours/imgItaAndAlps/7324*img Since somewhere between r3642 and r3695 ( incl. current 3705) that is generating a map with broken address search (either the country does not appear in the list). It took sometime to discover that now I need to move the typ file at the end of first section java -Xmx2000M -jar ./mkgmap/mkgmap.jar --max-jobs --latin1 --output-dir="./img"/ \ --family-id=10030 --product-id=1 --route --remove-short-arcs --bounds=bounds.zip \ --precomp-sea=sea.zip --location-autofill=is_in,nearest --draw-priority=20 --index --housenumbers --gmapsupp ./work/7311*osm.pbf *./typ/gspeed.typ* \ --family-id=10031 --product-id=1 --draw-priority=10000 --transparent./contours/imgItaAndAlps/7324*img What is weird is that the 1st command line seems to work for small files or if I remove the contour line (last line - also if I keep the typ before the pbf) and that the typ file is ignored by main map if it is just at the end of the whole command line. Maybe it makes sense to better document where to place a typ file in http://www.mkgmap.org.uk/doc/options ...just avoid someone else to get crazy! Regards, Enrico

2 3

Parameter order for index search - any impact?
by Enrico Liboni 17 Dec '16

17 Dec '16

Is there any difference in how index is build depending on parameters order? If I use: --housenumbers --index --gmapsupp I get a 97888256 byte file If I use: --gmapsupp --index --housenumbers I get a 97884160 byte file but index search seems to work the very same. Thanks, Enrico

2 1

Commit r3730: Merge file-encoding branch
by svn commit 17 Dec '16

17 Dec '16

Version mkgmap-r3730 was committed by steve on Sat, 17 Dec 2016 Merge file-encoding branch - Fix file encoding issues to the licence-file, copyright-file options. - Fix encoding issues in TDB and MPS files. http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3730

1 0