April 2024 - mkgmap-dev - The mkgmap lists

arabic translation to latin
by Thomas Morgenstern 29 Apr '24

29 Apr '24

Hello at All, in some tiles from africa are only name-tags as name:ar=<anywhat>. Example : OSM -ID 786.582.586 : addr:street= <arabic chars> ; amenity=hospital; healthcare=hospital; name:ar=<arabic chars>. If I compile this tile with code-page=1252, there shows up as name very cryptic like _/Mstshf ~?Lt?Hyl. /_If I use codepage=65001 ,then shows up the original arabic chars. But I am not able to read arabic. Because that I am looking for a solution to automatic translation from arabic to latin. mkgmap includes already a translation-table. But this table do not contain arabic. Can you give me any hints for integrating arabic to latin ? How to expand this table? It should contain also arabic. thanks thomas

2 2

translation table row02.trans
by Thomas Morgenstern 28 Apr '24

28 Apr '24

Hi, in mkgmap-r4919 exists inpath .\examples\chars\ascii\row02.trans. It seems for me, that the table translate listed chars UTF8. Does anybody know, how can we use this table ? Is there an option to get the table working und it should translate the letters in name= *tag ? regards thomas

1 0

UBUNTU JVM
by Thomas Morgenstern 15 Apr '24

15 Apr '24

Hello, under W10 ,32 GB RAM, Ryzen 7- 8 Core, mkgmap-r4919 (and also previous versions) stops processing large data sets after about 600 tiles. That's why I installed an UBUNTU 22-04 system. And the java-1.11.0-openjdk, installs jdk-21-oracle-x64 and jdk-22-oracle-x64 machines. None of the JVM works. On java-1.11.0, Ubuntu crashes completely after starting mkgamp. Under jdk-21, mkgmap creates ~40 tiles and the terminal exits. Under jdk-22 mkgmap creates ~40 tiles and the terminal closes. Which JVM on UBUNTU needs to be installed to fix this error? Under Windows 10, the generation ends after ~ 600 tiles from 1215 tiles. Why? What do you have to set up on W10 to make mkgmap work to the end ? Half a year ago, this went without any problems. Now it doesn't work on W10 or Linux. Hints very welcome. thomas

2 1

Patch to update documentation for splitter
by Gerd Petermann 08 Apr '24

08 Apr '24

Hi all, the attached patch adds a hint that holes in *.poly files are ignored. It also adds the --polygon-desc-file option in splitter.txt. Unfortunately I don't know how to test the formatting in the various formats, esp. the man page. Would be nice if someone on a linux system could test this. Gerd

3 9

Commit r4919: Avoid possible integer overflow in blocksize calculation when gmapsupp contains large number of tiles
by svn commit 04 Apr '24

04 Apr '24

Version mkgmap-r4919 was committed by gerd on Thu, 04 Apr 2024 Avoid possible integer overflow in blocksize calculation when gmapsupp contains large number of tiles http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4919

1 0

Error in gmapsupp blocksize calculation with huge number of tiles
by Gerd Petermann 04 Apr '24

04 Apr '24

Hi all see https://www.mkgmap.org.uk/pipermail/mkgmap-dev/2024q2/034252.html I think the experiments by Felix Herwegh showed a bug in the blocksize calculation. If the user combines a huge number of tiles (e.g. 6000) in one gmapsupp the code may not find the best blocksize due to an integer overflow. Not sure, maybe this also happens with < 2048 tiles in some cases. The attached patch fixes the calculation. It will result in smaller gmapsupp sizes where the error occured. Gerd

1 0

split using --polgon-file
by Felix Herwegh 04 Apr '24

04 Apr '24

Hi, recently I started playing with splitting using polygon files, primarily based on the documentation in https://www.mkgmap.org.uk/doc/splitter.html. Got it to work, even with multiple areas in one .poly file (testing only, no application). The idea is to better cut out neighboring countries' and sea area for countries poorly aligned to lat/lon (NL, BE, IT...). Digging deeper though, severeal questions arose, that I couldn't answer, neither by the doc mentioned above nor by the (seemingly somewhat more topical but brief) --help output of splitter, not even by searching this lists archives. 1. Although the doc for --polygon-files says: "If the polygon area(s) describe(s) a rectilinear area with no more than 40 vertices, splitter will try to create output files that fit exactly into the area, otherwise it will approximate the polygon area with rectangles." So far I have not been able to generate a single split, that exactly follows the polygon, even if quite simple (<<40 points). I always get tiles on or extending the polygone. I'm not shure, I understand that quoted sentence. Does it (for a single area) mean a polygone of <= 41 points, hence <=40 lines (if first and last point are identical)? Is this functionatlity still in place, or has it been deprecated? Neither am I shure, I understand the target. Should splitter generate non-rectangular tiles with an alignment according to a polygone at all, or only rectangular aligned to lat/lon? If the latter, "exactly follows" could only work for polygones having each line parallel lat or lon? 2. The .poly files should follow the Osmosis syntax, which also specifies: "The polygon section name may optionally be prefixed with "!" to subtract the polygon. The section(s) containing the larger area from which to subtract should be listed first. All the polygon sections are combined together to create the final filter area." I couldn't make that work. Tried "!" directly in front of the section-name, separated by blank and on an individual line. Splitter does not complain, but seems generate identical splits for all 3 tries and without that area specified at all. Does splitter respect this syntax at all? (testing only, no application) 3. From what I've read so far, one might want to aim for "solution is nice", sufficiently even distributed node counts over all tiles, right? Is that 80% tiles @ > 80% targeted nodes and <3% tiles below 33% targeted nodes? Why do I get nice solutions although (after having the search limit being increased in several steps) splitter comments "No good solution found, trying to find one accepting anything"? What would define a good split? 4. My initial approach was to increase tile count to better follow the polygone. I basically did that by decreasing --max-nodes and, when splitter ran into tiles having >100% targeted nodes, raising resolution to allow for those tiles (cities...) to be smaller. I eaven had the "feeling", that my Edge 1040 appreciated more smaller tiles by zooming and scrolling smoother. On the other hand from the doc and for example some discussion here between Gerd and Felix Hartmann regarding and around r609 release I've got the impression, that the typical target might be minimum tile count, as long as some (Garmin?) max. tilesize (?) is not reached. Why is that? 5. Increasing a significant portion of Germany maps tile count ~by factor 7 from ~280 tiles (@ max-nodes=1200000, resolution=13) to ~2000 tiles (@ max-nodes=150000, resolution=15) only took around an additional 8% in gmappsupp filesize, but another factor of 3 to ~6000 tiles (@ max-nodes=50000, resolution=??) made it "explode" to 300% of the original size. This map did still load (altough with some spinner delay) in QMapShack, but no longer on my Garmin device, not even got listed. Just out of curiosity: I can understand some increased overhead due to more tiles (as in the first step), but no progressive increase like this, since the OSM data basically stays identical. Is there some distinct border effect involved, like having to switch to some bigger data-type at some tile count or something similar? 6. Not being mentioned in the doc but (briefly) in the --help output at least 2 options seem to be accessible and might be involved: a) --search-limit, seems to be set and increased automatically if needed b) --num-tiles, seems to be unset/unused by default Any use to temper with a), p.e. start below default? What would be the difference (benefit?) of using b) over decreasing max-nodes to control tile count? Sorry for so many questions; thanks for any input ;-) //Felix Herwegh

2 3