February 2022 - mkgmap-dev - The mkgmap lists

Fix and augment sort definitions
by Gerd Petermann 12 Oct '23

12 Oct '23

Hi Ticker, see https://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3948 https://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3949 the sortResource.patch reverts these changes. In Mapsource the results are a bit better with your patch. I'll try again with my Oregon later. Gerd

3 15

some findings about NT format
by Gerd Petermann 15 Apr '22

15 Apr '22

Hi all, my findings so far which are not used / needed in GPXSee. Maybe it helps someone else: - method linkLabel() could extract further road labels, bit 0x800000 flags the last of up to 4 labels. - method linkLabel() extracts a flag, the bit 0x08 in this flag seems to signal a tunnel. No idea yet what the other bits mean. - the flags field in struct LinkInfo is used like this (netfile.cpp) bool firstIsShape = (linkInfo.flags >> 10) & 1; bool singleTopology = (linkInfo.flags >> 9) & 1; bool hasLevels = (linkInfo.flags >> 11) & 1; My guesses about the meaning of the lower bits: // int road_speed = linkInfo.flags & 7; // bool oneway = (linkInfo.flags >> 3) & 1; // int road_class = (linkInfo.flags >> 4) & 7; - The NET header can have two more sections, e.g. I see 00000684 | f6 cb 13 00 | NET5 ???, offset 13cbf6 00000688 | 96 0a 01 00 | NET5 ???, length 68246 0000068c | 23 00 | ??? 0000068e | 8c d6 14 00 | NET6 ???, offset 14d68c 00000692 | 28 05 00 00 | NET6 ???, length 1320 00000696 | 03 00 | NET6 ??? record size 3 00000698 | 02 00 00 00 | ??? NET6 contains a list of offsets into NET4, they are in sorted order and each offset points to the byte following the flag byte that is read in linkLabel() I see 440 recrods here, and 441 NOD6 records in the corresponding NOD file, so they are obviously related (field blockIndexId). I've not yet found where the address info like city name, zip name, and house numbers are stored. Maybe that's in NET5. I think in the old non-NT format there is no need to know NOD data to be able to read NET, so I woulld expect that this is also possible with NT maps. Gerd

4 11

Commit r4897: merge (again) from faster-mp branch
by svn commit 25 Feb '22

25 Feb '22

Version mkgmap-r4897 was committed by gerd on Fri, 25 Feb 2022 merge (again) from faster-mp branch http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4897

1 0

option link-pois-to-ways information
by Ticker Berkin 21 Feb '22

21 Feb '22

Hi all To improve routing, I'd like to get information about the POIS that are being linked to a WAY that can be used as part of the style/lines processing. The problem I'm trying to solve is to restrict car routing through some types of very low level roads (eg service) when there is a barrier. Setting mkgmap:throughroute=no on these works nicely with MapSource and older devices but BaseCamp and newer devices will happily route over a footpath to avoid a throughroute=no section. At the moment, with --link-pois-to-ways, if the POI has a barrier or highway tag, mkgmap:way-has-pois is set true. This can be tested by lines, inc/access etc, but there is no way to find out if it is a significant barrier or something like highway=street_lamp. points processing can set mkgmap: access & road_speed/class variables that are handled by inbuild code after lines processing to imposes more restrictions on the way and/or reduces speed/class; this is no use for what I want to do. Possibilities are: 1/ have options to say which POI tag/value combinations cause link-pois-to-ways 2/ set new variables on the way, eg mkgmap:barrier_tags/highway_tags, which are a list of distinct POI highway/barrier tag values. Ticker

3 16

splitter with --polygon-desc-file crashes
by 7770 16 Feb '22

16 Feb '22

Hi. I have asked long ago about this particular problem i have and it was long time ago i last tried, but now i did again. It relates to splitter and usage of --polygon-desc-file= This is how i have tried: 1. Download data for Estonia and Latvia. https://download.geofabrik.de/europe/estonia-latest.osm.pbf https://download.geofabrik.de/europe/latvia-latest.osm.pbf 2. convert to o5m and combine osmconvert estonia-latest.osm.pbf -o=estonia-latest.osm.o5m; osmconvert latvia-latest.osm.pbf -o=latvia-latest.osm.o5m; osmconvert estonia-latest.osm.o5m latvia-latest.osm.o5m -o=ee_lv.o5m; 3. Prepare an osm-polygon file with one area for Estonia and one for Latvia. (file attached) 4. Run splitter: java -Xmx2000m -jar ${SPLITTER} \ --polygon-desc-file=./polygon_ee_lv.osm \ --output-dir=ee_lv/splitted/ \ --max-nodes=750000 \ --no-trim \ ee_lv.o5m While running this is seems like the Latvia part is fine, but the Estonia crashes. The error message doesn't say much (that i understand). But maybe it makes some sense to you? I imagine something is wrong with the polygon file, but i dont know what. The polygon files is partially made in JOSM and partially manaully to re-use the same segments/edges which belong to both countries. (I could see that Gerd was using this concept in some example file for Germany and the alps, but i could not add two ways over one edge in JOSM, so i made manual chanegs in the file). I tried also making two separate boxes, one for each country, but that was just as bad (not reusing edges). Anything that could be suggested that i change or try? PS. i am trying this on small scale for two smaller countries, later i will apply it because i need to split europe in parts of max 4GB. Regards Karl

2 2

Patch: use all 4 bytes of POIGlobalFlags in LBL Header
by Gerd Petermann 12 Feb '22

12 Feb '22

Hi devs, attached patch simplifies the code, but should not change anything in the output of mkgmap. GPXSee contains code to evaluate some of the bits which were ignored so far. Do you see any problems? Gerd

3 6

Commit r4896: step 1 of partial merge from mdr2 branch
by svn commit 11 Feb '22

11 Feb '22

Version mkgmap-r4896 was committed by gerd on Fri, 11 Feb 2022 step 1 of partial merge from mdr2 branch - don't render natural=coastline as lines, this is rarely useful - don't fill string table and don't create tempFile for strings when calculating global index for gnapsupp. This reduces I/O and peak memory usage. http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4896

1 0

Work in progress and the mdr2 branch
by Gerd Petermann 10 Feb '22

10 Feb '22

Hi all, during the last days I've mainly rewritten GPXSee code in Java to be able to understand all the new structures in NT format. I am making progress but it will probably take weeks until I really understand any of it. The code in GPXSee is written to be very fast and it silently stops reading whereever bits or bytes have unexpected values, something that we cannot do when we want to be able to write that format. Most confusing for me is that it reads parts of the NOD file backwards (at least I think that is what class BitStream4R does). Anyway, while debugging I see data that looks correct, e.g. some road geometry and labels match the data shown in GPXSee, so I think it's just a matter of time to get to the point where GPXSee is now. I wonder if I should try to merge the mdr2 branch into trunk first? It's major changes so far are: - ability to use Huffman compression MDR15 (the string table in the global PC index *_mdr.img) - different (hopefully better) handling of mixed cased labels (--lower-case option) - changes from the faster-mp branch - possibly more memory needed to write global POI index (mdr11) - default style change to not render natural=coastline as line (*) - reduced I/O because no strings temp file written for gmapsupp index (*) (*) It would be quite easy to do this in trunk as well without merging the rest of the changes Gerd

3 2

Commit r4895: oops, 4894 caused a change (and infinite(?) loop in unit test
by svn commit 04 Feb '22

04 Feb '22

Version mkgmap-r4895 was committed by gerd on Fri, 04 Feb 2022 oops, 4894 caused a change (and infinite(?) loop in unit test http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4895

1 0

Commit r4894: code simplification (no functional change)
by svn commit 04 Feb '22

04 Feb '22

Version mkgmap-r4894 was committed by gerd on Fri, 04 Feb 2022 code simplification (no functional change) - use new readSectionInfo http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4894

1 0