- mkgmap-dev - The mkgmap lists

Check Roundabouts improvements
by Mike Baggaley 19 Dec '16

19 Dec '16

Hi Gerd/Steve, Please find attached a patch for improvements to the warnings displayed when using the --check-roundabouts option. This also brings the documentation for the --check-roundabouts option up to date and corrects an unrelated minor typo when reporting duplicate POIs. There is no change to the generated map. The change identifies highways that go inside the roundabout, and reports coincident highways joining the roundabout differently if one or more of the highways is inside the roundabout - these are much less likely to need correction in OSM than those where more than one highway joins at the same point from outside the roundabout. Note, the patch seems to replace large parts of the options.txt and options files - this is because my editor rationalised the line endings which were inconsistent, sometimes using LF and sometimes CRLF. Please review, test and commit if all seems to be OK. Thanks, Mike

2 1

splitter r524 ready for merge into trunk
by Gerd Petermann 19 Dec '16

19 Dec '16

Hi all, I think r524 in the refactoring2 branch is ready for trunk. Major changes compared to r476 in trunk: - it is faster because it uses an additinal thread for the reader (as long as the max-threads option is not 1) and some other optimizations, esp. in the o5m parser. I think 20% can be expected because of this. - the limit in the area "dictionary" (65535) was removed, it is now > 2.147.483.648 which should be enough for a long time ;-) The change was possible due to optimizations in the map structures, the memory footprint is very close to r476, possibly even smaller in most situations. - the max-areas limit is now 9999, the default is now 2048 instead of 512. - invalid options are no longer changed to default values. Splitter will stop instead. - in some cases the split algorithm finds a better split (fewer tiles) for a given max-nodes value. - fewer stdout messages about map contents If I hear no problems I'll merge next monday. The link to the latest binary can be found at the bottom of this page: http://www.mkgmap.org.uk/download/splitter.html Gerd

3 2

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