June 2021 - mkgmap-dev - The mkgmap lists

Re: [mkgmap-dev] Embedding raster maps
by Oliver Eichler 25 Jan '22

25 Jan '22

Hi Steve, thanks for the file. On my device nothing is visible at all. But that's kind of an information, too. There is no way to circle down bugs by simply skipping the extended part. Probably it is still some missing encoding. In the Isle of Man map (and others) there is much more information in the RGN header. Note the values in the "filling bytes". And there seems to be an additional section after the extended point2 section. I called it offset1/length2. --- RGN header --- size 007D type 47 41 52 4D 49 4E 20 52 47 4E | GARMIN RGN byte0x0000000C 01 flag 00 year 2010 month 7 day 21 hour 9 minute 53 second 6 offset1 0000D54E length1 00000000 offset_polyg2 0000D54E length_polyg2 00001A1F byte0x00000025_0x00000038 02 00 00 00 00 00 00 00 FF 00 00 20 FD FC 03 00 00 00 00 00 offset_polyl2 0000EF6D length_polyl2 00000000 byte0x00000041_0x00000054 00 00 00 00 00 00 00 00 3F 00 00 20 FD 0F 00 00 00 00 00 00 offset_point2 0000EF6D length_point2 00000000 byte0x0000005D_0x00000070 00 00 00 00 00 00 00 00 FF 07 00 20 3F F7 3F 00 00 00 00 00 offset2 0000EF6D length2 0000020B unknown 000000E3 This section has a variable length in different sub-files. The unknown value E3 can be E5, too. It doesn't seem to be a record size. I had a look at several sections. They are not completely random, thus there seem to be no "compression". However the patterns do not ring a bell for me. I copied a couple of them into a file and loaded it into my cloud share: https://www.magentacloud.de/share/s429h1z-r6 Maybe one of you has an idea what it's about. I also uploaded my current version of the test map with a single raster map tile. It does not show. Top left coordinate is N46° 57.768 E011° 47.484. Sadly I am stuck here and I am running out of quality time to concentrate on the topic. I also have to update QMapShack's decoding. While reading the mkgmap source code I noticed a lot of new stuff that is not covered by the decoder. Cheers Oliver

4 6

new splitter branch solve-parallel
by Gerd Petermann 01 Jul '21

01 Jul '21

Hi all, I've started this branch to further improve the split results. Splitter has two different algorithms to find good splits. 1) Algo FULL tries first to split in the middle and then continues with the next positions (mid+1, mid-1, mid+2, mid-2, ...) The resulting parts are split again recursively. This should find the best possible split but can take very long when the only good split starts far from the middle. 2) Algo SOME uses some heuristics to test only some of the possible splits. This is typically much faster but sometimes doesn't find any solution and sometimes the FULL algo finds a better solution. The trunk version tries first the one that is more promising and - if that fails to find a good split - tries the other. So, sometimes the FULL algo works for 2 minutes and then SOME finds a good result in a few seconds. This branch executes both algorithms in parallel and uses the better result. One of the open problems is to decide under what conditions the execution should stop. If the SOME algo finds a good solution within 20 secs should we still continue the FULL algo to find the best solution? If yes, how long? I'm playing with this, any input is welcome. Gerd

4 5

splitter r609 released
by Gerd Petermann 01 Jul '21

01 Jul '21

Hi all, I think with r609 there should be no need to use a polygon file. See https://www.mkgmap.org.uk/websvn/revision.php?repname=splitter&rev=609 Please let me know when this version produces much worse results compared to older releases (using the same options and input) and provide the files densities-out.txt and the log. If you are interested in good splits you should check the splitter log for "Solution is not nice. Can't find a better solution" When this is printed splitter did not find a good split. Expect almost empty tiles in this case. It is likely that this happens when rather small files are split with a polygon and the default resolution. Normal users don't do this, but some map providers try to use the same options for very different downloads ... Gerd

3 13

problems edge1030
by Arndt Röhrig 30 Jun '21

30 Jun '21

3 5

Minor spelling bug
by Manfred Haiduk 29 Jun '21

29 Jun '21

Hi all as i have just opened the url https://www.mkgmap.org.uk/download/mkgmap.html i found a minor spelling bug. Instead of writing "--precomp-sea option" someone has omitted one letter "p" and there is written "--precom-sea option" If someone has time and could change this ? 😁 Mit freundlichen Grüßen ##################################################### Manfred Haiduk, Zum Fischbach 9, 52393 Hürtgenwald e-mail mhaiduk(a)t-online.de #####################################################

2 1

Commit r4793: revert major bug in relation handling that was introduced with r4784 in the low-res-opt branch
by svn commit 26 Jun '21

26 Jun '21

Version mkgmap-r4793 was committed by gerd on Sat, 26 Jun 2021 revert major bug in relation handling that was introduced with r4784 in the low-res-opt branch http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4793

2 1

problem with boundarys
by Arndt Röhrig 26 Jun '21

26 Jun '21

2 2

problem with gmapi and lonf name for TYP file
by Gerd Petermann 25 Jun '21

25 Jun '21

Hi, in a private mail from Thomas Morgenstern I was informed that mkgmap may write invalid gmapi data if the typ file has a long name. I can reproduce this problem with a single input file and our sample typ file like this java -jar dist\mkgmap.jar --gmapi resources\typ-files\sameOrder.txt 63240001.o5m The problem shows up in Mapsource which cannot create gmapsupp files for such a gmap file, it crashes instead I guess mkgmap should use the same name for the gmapi format that is used for the gmapsupp.img, so SAMEORDE.TYP Or maybe the family id should be used instead, e.g. 6324.TYP? Gerd

2 1

mkgmap-faster-mp-r4790 (warning and crash)
by 7770 25 Jun '21

25 Jun '21

Hi. Posting an error report. I was running the mkgmap-faster-mp-r4790 to generate maps. It trows a few errors and then crashes on a later pbf file. 4769 does not crash. It is most likely this pbf that make it crash: https://files.mkgmap.org.uk/detail/514 I also observed that 4790 procuces a tiny bit larger tiles than 4769, but maps that did not crash work fine. ALLVARLIG (ShapeSplitter): syd/splitted/77800065.osm.pbf: Horizontal split 121664384 failed on shape at http://www.openstreetmap.org/? mlat=40.777236&mlon=0.641794&zoom=17 Possibly a self-intersecting polygon ALLVARLIG (ShapeSplitter): syd/splitted/77800079.osm.pbf: Vertical split -3407872 failed on shape at http://www.openstreetmap.org/? mlat=42.764267&mlon=-1.308690&zoom=17 Possibly a self-intersecting polygon ALLVARLIG (ShapeSplitter): syd/splitted/77800079.osm.pbf: Vertical split -3670016 failed on shape at http://www.openstreetmap.org/? mlat=42.924310&mlon=-1.142578&zoom=17 Possibly a self-intersecting polygon ALLVARLIG (ShapeSplitter): syd/splitted/77800079.osm.pbf: Vertical split -3538944 failed on shape at http://www.openstreetmap.org/? mlat=42.762094&mlon=-1.230469&zoom=17 Possibly a self-intersecting polygon ALLVARLIG (ShapeSplitter): syd/splitted/77800079.osm.pbf: Horizontal split 127951872 failed on shape at http://www.openstreetmap.org/? mlat=42.880383&mlon=-1.135497&zoom=17 Possibly a self-intersecting polygon ALLVARLIG (ShapeSplitter): syd/splitted/77800079.osm.pbf: Horizontal split 127886336 failed on shape at http://www.openstreetmap.org/? mlat=42.871682&mlon=-0.965080&zoom=17 Possibly a self-intersecting polygon ALLVARLIG (ShapeSplitter): syd/splitted/77800079.osm.pbf: Vertical split -3538944 failed on shape at http://www.openstreetmap.org/? mlat=42.762094&mlon=-1.230469&zoom=17 Possibly a self-intersecting polygon ALLVARLIG (ShapeSplitter): syd/splitted/77800079.osm.pbf: Vertical split -3473408 failed on shape at http://www.openstreetmap.org/? mlat=42.766285&mlon=-1.186523&zoom=17 Possibly a self-intersecting polygon ALLVARLIG (ShapeSplitter): syd/splitted/77800079.osm.pbf: Horizontal split 127951872 failed on shape at http://www.openstreetmap.org/? mlat=42.880383&mlon=-1.135497&zoom=17 Possibly a self-intersecting polygon ALLVARLIG (ShapeSplitter): syd/splitted/77800079.osm.pbf: Horizontal split 127886400 failed on shape at http://www.openstreetmap.org/? mlat=42.871695&mlon=-0.965059&zoom=17 Possibly a self-intersecting polygon ALLVARLIG (ShapeSplitter): syd/splitted/77800079.osm.pbf: Horizontal split 127945984 failed on shape at http://www.openstreetmap.org/? mlat=42.877257&mlon=-0.977003&zoom=17 Possibly a self-intersecting polygon ALLVARLIG (StyledConverter): syd/splitted/77800122.osm.pbf: Attention: Tile contains both drive-on-left (17826) and drive-on-right roads (20713) ALLVARLIG (global): Unexpected error java.lang.IndexOutOfBoundsException: Index: 0 at java.util.Collections$EmptyList.get(Collections.java:4454) at uk.me.parabola.mkgmap.filters.ShapeMergeFilter.findBestMerge(ShapeMergeFilter.java: 534) at uk.me.parabola.mkgmap.filters.ShapeMergeFilter.tryMerge(ShapeMergeFilter.java: 393) at uk.me.parabola.mkgmap.filters.ShapeMergeFilter.addWithConnectedHoles(ShapeMergeFilter.java: 335) at uk.me.parabola.mkgmap.filters.ShapeMergeFilter.tryMerge(ShapeMergeFilter.java: 238) at uk.me.parabola.mkgmap.filters.ShapeMergeFilter.mergeSimilar(ShapeMergeFilter.java: 149) at uk.me.parabola.mkgmap.filters.ShapeMergeFilter.merge(ShapeMergeFilter.java:104) at uk.me.parabola.mkgmap.build.MapBuilder.makeSubdivision(MapBuilder.java:933) at uk.me.parabola.mkgmap.build.MapBuilder.makeMapAreas(MapBuilder.java:833) at uk.me.parabola.mkgmap.build.MapBuilder.makeMap(MapBuilder.java:328) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:114) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:70) at uk.me.parabola.mkgmap.main.Main.lambda$processFilename$1(Main.java: 290) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java: 1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java: 624) at java.lang.Thread.run(Thread.java:748) ALLVARLIG (global): Exiting due to unexpected error Number of ExitExceptions: 1 Time finished: Fri Jun 25 04:01:05 CEST 2021 Total time taken: 35 minutes 36 seconds Regards Karl

2 3

Commit r4791: prevent possible IndexOutOfBoundsException in ShapeMergeFilter
by svn commit 25 Jun '21

25 Jun '21

Version mkgmap-r4791 was committed by gerd on Fri, 25 Jun 2021 prevent possible IndexOutOfBoundsException in ShapeMergeFilter http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4791

1 0