June 2021 - mkgmap-dev - The mkgmap lists

mkgmap-faster-mp (follow up)
by 7770 06 Jun '21

06 Jun '21

Hi. After long time i am returning to the issue of long generation time for tiles with large polygons. I have avoided interfering with the discussion as i am not in the position to help on the technical details. The original tile for which there was an issue was used in the following test, can be found here: https://files.mkgmap.org.uk/detail/502 On my computer, compiling the split data (from link above): with version mkgmap-faster-mp-r4706 it takes around 2 minutes 40 seconds, output size 13520896 bytes. with version mkgmap-r4745 it takes around 25 minutes and 30 seconds, output size 13516800 bytes. This is a great change! With an earlier version of the mkgmap-faster-mp i have compiled maps with no problem, but with 4706 i get the following error in one case. (split data can be uploaded in case you want, 77700020*.pbf). What could be the issue? Mkgmap version 4706 Time started: Sat Jun 05 08:09:29 CEST 2021 ALLVARLIG (global): Unexpected error java.lang.ArrayIndexOutOfBoundsException: -1 at java.util.ArrayList.elementData(ArrayList.java:422) at java.util.ArrayList.get(ArrayList.java:435) at uk.me.parabola.mkgmap.reader.osm.MultiPolygonRelation.getLargest(MultiPolygonRelation.java: 674) at uk.me.parabola.mkgmap.reader.osm.MultiPolygonRelation.processElements(MultiPolygonRelation.java: 640) at uk.me.parabola.mkgmap.reader.osm.ElementSaver.addRelation(ElementSaver.java: 163) at uk.me.parabola.mkgmap.reader.osm.bin.OsmBinHandler$BinParser.parseRelations(OsmBinHandler.java: 215) at crosby.binary.BinaryParser.parse(Unknown Source) at crosby.binary.BinaryParser.handleBlock(Unknown Source) at crosby.binary.file.FileBlock.process(Unknown Source) at crosby.binary.file.BlockInputStream.process(Unknown Source) at uk.me.parabola.mkgmap.reader.osm.bin.OsmBinHandler.parse(OsmBinHandler.java: 54) at uk.me.parabola.mkgmap.reader.osm.OsmMapDataSource.parse(OsmMapDataSource.java: 166) at uk.me.parabola.mkgmap.reader.osm.OsmMapDataSource.load(OsmMapDataSource.java: 141) at uk.me.parabola.mkgmap.main.MapMaker.loadFromFile(MapMaker.java:165) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:58) 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: Sat Jun 05 08:09:42 CEST 2021 Total time taken: 13 seconds Regards Karl

2 3

Commit r4758: merge fix for IsInUtil from faster-mp branch
by svn commit 06 Jun '21

06 Jun '21

Version mkgmap-r4758 was committed by gerd on Sun, 06 Jun 2021 merge fix for IsInUtil from faster-mp branch http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4758

1 0

BaseCamp_Route_Is_Reversing, GPS_Route_Is_Reversing
by ankeric.osm＠gmail.com 05 Jun '21

05 Jun '21

Since a very long time (assumption: 2014, BaseCamp 4.3.3) BaseCamp routing will - sometimes - reverse, bites its own tail. I have always assumed this is a Garmin BaseCamp error. Is started with a specific BaseCamp version. But it may have coincided with a mkgmap update ???? Garmin has always been assuming it’s mkgmap that is responsible for this. To avoid the error: - Remove the viapoint after which the route is reversing (goes backwards). - Put viapoint ON junction, not in the middle or beginning of a highway. - Avoid putting a viapoint besides the highway. Attached: BaseCamp_Route_Is_Reversing.png BaseCamp_Route_Is_Reversing.gpx Route direction: from east to west. East or arrow: route is correct. West of arrow: route is reversing. Map used for reproducing: OSM_MKGMAP_DEFAULT (But it’s reproduced on all maps (my own Bike_Map, OpenFietsMap, OSM_MKGMAP_GENERAL). I've seen it happen on GPSMAP 66s as well. Attached: BaseCamp_Route_Is_Reversing_12307.bmp Route navigation here comes from the south and should turn right (east) over the bridge. But GPS indicates to go straight on and after 80 meters: turn round, reverse, U-turn. No nodes close junction; highway south = unclassified, highway north and east = secondary Eric (AnkEric)

2 2

special case where splitting fails without a log message
by Gerd Petermann 03 Jun '21

03 Jun '21

Hi Ticker, while looking at the problems with sea I found this case where ShapeSplitter removes a small part of an island from a self-intersecting polygon in res 24. Compiled with mkgmap from trunk, default style and no options. Look at 67.6742611, 14.6783525 Found this with some check code that compares the area of the original polygon with that of sum of the parts. Gerd

4 44

Re: [mkgmap-dev] Basecamp crashes on search if searching for many 2+ word phrases
by Felix Hartmann 02 Jun '21

02 Jun '21

Even though Gerd also speaks German, I think its better to continue in English. I am quite sure that this is the same bug then. Your map does not crash because it find another POI first. I also sometimes have two POI for the same thing - one for finding it via a category POI search, the other for the symbol in the map. I do wonder if you have two POI the order in the style matters? If you change the order they are created - does it crash? Could it be that only 0x1234 POI are affected, but the newer 0x12345 types not? As soon as it finds 0x12345 it does not crash? Lets take Verbier Village - it is not a ciy POI https://www.openstreetmap.org/node/8307159228 I use: highway=bus_stop | amenity=bus_stop | highway=busstop | amenity=busstop | railway=bus_stop {set name='bus_stop ${name}' | 'bus_stop' } [0x2f17 resolution 24] for that one. Cold de Jaman https://www.openstreetmap.org/node/1437437792 I have the rule: 0x1c01 resolution 24 continue] [0x11607 resolution 20-21 continue] [0x1151f resolution 22-22 continue [0x1151f resolution 23-24]] However the first one in my map obviously is 0x1c01 - an old type. The other ones are a bit bad examples I noticed - because there exists several entries in osm data that could be found with identical name. However I have found no actual city only poi where it crashes - Saas Fee also has other POI named the same. So maybe they cause a crash. On Wed, 2 Jun 2021 at 10:25, Thomas Morgenstern <webmaster(a)img2ms.de> wrote: > Kann sein, dass es am Style liegt. Ich nutze meinen eigenen Style, der > z.B einen zusätzlichen POI für Städte einfügt. ich fand vor geraumer > Zeit, dass Städte in der MDR nicht eingebbar sind, wenn der String > Leerzeichen enthält. Dazu hatte ich auch in der mailinglist gepostet. > Hr.Petermann sagte damals, das die MDR für Städte aber nicht anpassbar sei. > deshalb hat bei mir jede Stadt noch einen zusätzlichen POI einer anderen > Kategorie. > mfg > > Am 02.06.2021 um 09:07 schrieb Felix Hartmann: > > Very strange - I also tested this on "Frezeitkarte" Schweiz and it crashed > too. It usually does not crash if you before had a non crash search. > > On Wed, 2 Jun 2021 at 08:35, Thomas Morgenstern <webmaster(a)img2ms.de> > wrote: > >> Kann ich nicht bestätigen, alle hier genannten Suchen sind erfolgreich ohne >> Abstutz. BC Ver 4.7.0 und eigene OSM map >> mfg >> >> Am 01.06.2021 um 22:32 schrieb Felix Hartmann: >> >> A user of my maps just told me that there are some crashes in the >> Basecamp search. There is a clear pattern - only search phrases of minimum >> 2 words with a space between cause crashes. >> >> I tested it on my maps, and on other mkgmap created maps and the crashes >> are more or less happening on all maps. >> >> >> For Switzerland some places causing crashes: >> Verbier Village >> Saas Fee >> Col de Jaman >> Pic chaussy >> Pic chosy >> >> >> Also >> 2) the search must be the first from BC execution >> 3) if a good search already has been executed (single word), then the >> crash rarely occurs >> >> >> Not happening with Garmin's own maps. The more entries (POIs) of the name >> exist - the more likely? Seems to happen more often in the French part of >> Switzerland compared to the Garmin part. But as many words like Saas Fee do >> not contain any special characters - I do not think it is related to any >> codepage problem. >> -- >> Felix Hartman - Openmtbmap.org & VeloMap.org >> >> >> >> _______________________________________________ >> mkgmap-dev mailing listmkgmap-dev@lists.mkgmap.org.ukhttps://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >> >> >> > > -- > Felix Hartman - Openmtbmap.org & VeloMap.org > > > -- Felix Hartman - Openmtbmap.org & VeloMap.org

3 12

splitter default resolution 13 and overview map from default style
by Gerd Petermann 02 Jun '21

02 Jun '21

Hi all, I am not sure but I think it is a bad idea to have overview-levels = 4:17, 5:16, 6:15, 7:14, 8:12 in the default style. The lowest resolution is 12 while splitter uses the default 13 for its resolution. This also means that tiles from splitter are aligned to a resolution of 13. The lowest level in the overview map is therefore sometimes much more distorted at tile boundaries than the next higher. I think it should be changed to overview-levels = 4:17, 5:16, 6:15, 7:14, 8:13 I've never thought about this relationship between splitter and the overview map. Just wondered why my test data looks so ugly at resolution 12. An alternative would be to remove the lowest level completely. Maybe mkgmap should print a warning when tiles are not aligned for the lowest resolution used in the map? Any thoughts? Gerd

3 2

Commit r4735: improve Logging/ debugging : todegrees.patch
by Mike Baggaley 02 Jun '21

02 Jun '21

>Version mkgmap-r4735 was committed by gerd on Mon, 24 May 2021 >improve Logging/ debugging : todegrees.patch >- change Coord.toString() to return the same as toDegreeString() instead of a pair of Garmin units >- add method toGarminString() to get a string with Garmin units >- deprecate toDegreeString() It appears that display no longer compiles as it uses toDegreeString(): compile: [javac] Compiling 76 source files to C:\Users\Mike\Documents\MapBuild\Programs\display\build\classes [javac] C:\Users\Mike\Documents\MapBuild\Programs\display\src\test\svg\subdiv\SvgDiv Doc.java:83: error: cannot find symbol [javac] .setText(String.format("%d: %s", div.getNumber(), div.getCenter().toDegreeString())); [javac] ^ [javac] symbol: method toDegreeString() [javac] location: class Coord [javac] 1 error BUILD FAILED Cheers, Mike

2 1

Basecamp crashes on search if searching for many 2+ word phrases
by Felix Hartmann 01 Jun '21

01 Jun '21

A user of my maps just told me that there are some crashes in the Basecamp search. There is a clear pattern - only search phrases of minimum 2 words with a space between cause crashes. I tested it on my maps, and on other mkgmap created maps and the crashes are more or less happening on all maps. For Switzerland some places causing crashes: Verbier Village Saas Fee Col de Jaman Pic chaussy Pic chosy Also 2) the search must be the first from BC execution 3) if a good search already has been executed (single word), then the crash rarely occurs Not happening with Garmin's own maps. The more entries (POIs) of the name exist - the more likely? Seems to happen more often in the French part of Switzerland compared to the Garmin part. But as many words like Saas Fee do not contain any special characters - I do not think it is related to any codepage problem. -- Felix Hartman - Openmtbmap.org & VeloMap.org

1 0