May 2021 - mkgmap-dev - The mkgmap lists

How to search for osmid()=941762308
by ankeric.osm＠gmail.com 12 May '21

12 May '21

When an OSM-Mapper makes a mistake, I sometimes correct this Error (or difference in opinion) by using mkgmap. highway=* & osmid()=22689239 { set highway=track; set tracktype=grade1; delete service } Which is OK, accepted by mkgmap syntax. Yesterday I made a mistake as well: INNER in Multipolygon is untagged and JOSM doesn't warn (no warning: "Untagged ways (1)"). Today I tried to correct my mistake: osmid()=941762308 { set landuse=forest } But, mkgmap doesn’t accept my correction: SEVERE (global): Error in style: Error: (inc/DEBUG_begin:148): Invalid rule, expression cannot be indexed: osmid()=941762308 I was assuming osmid() is a Primary Key. How to search for a Primary Key using mkgmap, If the way is also untagged? BTW, JOSM can find (search): id=941762308. Eric (AnkEric)

3 3

Commit r4705: reduce peak memory in Mdr5.preWriteImpl() (called by combiners for --index)
by svn commit 11 May '21

11 May '21

Version mkgmap-r4705 was committed by gerd on Tue, 11 May 2021 reduce peak memory in Mdr5.preWriteImpl() (called by combiners for --index) mdr5Mem_v3.patch by Ticker Berkin http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4705

1 0

multipolygon label
by Mike Baggaley 11 May '21

11 May '21

Hi Gerd, Please find attached a small patch that fixes a problem with the use of the label role in multi-polygon relations. Currently, if a node has the role of label but has no name or a different name from the polygon, a message is output saying the node will not be used. However, it is used anyway. The patch stops the override and does not display a warning for a node with no name. Cheers, Mike

2 1

Re: [mkgmap-dev] Commit r4703: improve RoadMerger (based on merge-roads-reversed-v6.patch)
by Mike Baggaley 11 May '21

11 May '21

Hi Gerd, No problem with that, but I don't think it should be a hidden option, and the use of 'force' suggests it will reverse ways that are direction sensitive. I suggest --allow-reverse-merge and add it to the documentation stating that if your style includes mkgmap:has_direction is it on by default. I don't have any direction sensitive ways in my style and hence will need to use the option. Cheers, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 11 May 2021 12:21 To: Development list for mkgmap <mkgmap-dev(a)lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] Commit r4703: improve RoadMerger (based on merge-roads-reversed-v6.patch) Hi Mike, it is off by default because it will cause trouble with some styles / TYP files which rely on the direction but don't set that the new special tag (yet). Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces(a)lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike(a)tvage.co.uk> Gesendet: Dienstag, 11. Mai 2021 13:15 An: mkgmap-dev(a)lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Commit r4703: improve RoadMerger (based on merge-roads-reversed-v6.patch) Hi Gerd, I may be misunderstanding this, but the explanation of when it is enabled seems illogical. It seems to me that reversing should be the default except on ways that have mkgmap:has-direction=true unless a switch is given to disable it. Or it could be off by default and a switch enables it, except for ways that have mkgmap:has-direction=true. Cheers, Mike -----Original Message----- From: svn commit [mailto:svn@mkgmap.org.uk] Sent: 11 May 2021 11:22 To: mkgmap-svn(a)lists.mkgmap.org.uk; mkgmap-dev(a)lists.mkgmap.org.uk Subject: [mkgmap-dev] Commit r4703: improve RoadMerger (based on merge-roads-reversed-v6.patch) Version mkgmap-r4703 was committed by gerd on Tue, 11 May 2021 improve RoadMerger (based on merge-roads-reversed-v6.patch) This has two effects: - it allows RoadMerger to merge roads which build a sharp angle, if that is done an info message is logged - it allows RoadMerger to merge roads with different directions be reversing the order of points if special criteria are met - implement new special tag mkgmap:has-direction=true which tells mkgmap that the direction of the way is important and should not be reversed. The routing tags oneway=yes or oneway=-1 have the same effect, but they also effect routing. Use this tag if you have a TYP file which renders lines different (e.g. cycleway on the right or on the left side) to prevent a reverse merge - implements new experimental option --x-force-reverse-merge Merging with reverse produces smaller maps, esp. smaller NET and NOD files, it may have an influence on routing. Reversing of roads is disabled unless mkgmap detects that the style has at least one rule which adds mkgmap:has-direction=true in rule file lines or option --x-force-reverse-merge is used. The program checks if any line that was added for a given OSM way has the tag mkgmap:has-direction=true. If one is found the tag is propagated to the road(s) for that OSM way so no reversing happens. Roads with different direction attributes are not merged. The option --x-force-reverse-merge is meant for those who don't use a TYP file or don't render left/right attributes with different types. All others should not use the option and adapt the style instead. http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4703 _______________________________________________ mkgmap-dev mailing list mkgmap-dev(a)lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

2 1

Commit r4702: show stacktrace when OutOfMemoryError occurs, helps to decide if maxjobs should be decreased or if one of the combiners is the problem
by svn commit 11 May '21

11 May '21

Version mkgmap-r4702 was committed by gerd on Tue, 11 May 2021 show stacktrace when OutOfMemoryError occurs, helps to decide if maxjobs should be decreased or if one of the combiners is the problem http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4702

3 2

Commit r4704: detect duplicate roads to log a warning when the lines rules add equal routable lines for one OSM way and ignore them
by svn commit 11 May '21

11 May '21

Version mkgmap-r4704 was committed by gerd on Tue, 11 May 2021 detect duplicate roads to log a warning when the lines rules add equal routable lines for one OSM way and ignore them - Uses the code in RoadMerger to detect roads with equal attributes (type, resolution, speed, class, oneway, vehicles, ...) - Enable logging of warnings in StyledConverter to see those messages. This is not (yet) detecting two roads where all attributes are equal despite the min/max resolution. It might be changed to detect that later as this also blows up the IMG file for no good reason. Styles which add multiple roads for one OSM way should make use of mkgmap:highest-resolution-only=true anyway. http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4704

1 0

Duplicate roads added by default style
by Gerd Petermann 11 May '21

11 May '21

Hi all, while double checking patch for the RoadMerger I wondered what might happen if the style adds two or more identical roads for the same OSM way. Of course this makes no sense but to my surprise I found out that this really happens with the default style. A way with e.g. highway=footway and railway=platform is added twice ... highway=footway {set tmp:stopMopUp=yes} [0x16 road_class=0 road_speed=0 resolution 23 continue with_actions] ... railway=platform [0x16 road_class=0 road_speed=0 resolution 23] Of course the default style should be fixed to avoid that but I think mkgmap can detect this easily and should print a warning when the style does that? Gerd

5 11

patch: improve RoadMerger: allow to merge roads with reversed points
by Gerd Petermann 10 May '21

10 May '21

Hi all, up to now RoadMerger doesn't merge (combine) two roads if the have different directions. This is OK for oneway roads but I see no need for this with other roads. The attached patch changes this. It has an influence on file size (safes a few KB in each tile) and very likely also on routing, hopefully to the better/faster. It also reduces zig-zagging in the low-res-opt branch. Strangely enough almost all was already implemented, so maybe WanMil (the original author) tried that before and found a reason not to do it. Will search the archives later... Gerd

5 24

Empty rectangles in map
by Gerd Petermann 10 May '21

10 May '21

Hi Experts, while working on the faster-mp branch I experimented with the monster relation r9488835. I added tag landuse=forest to it so that it is actually rendered and found huge (wrong) empty rectangles in the forest. The original file is very complex but the same problem also occurs with a simplified file, see http://files.mkgmap.org.uk/download/505/bad-map-split.osm.pbf Just use e.g. java -jar mkgmap.jar --gmapi bad-map-split.osm.pbf Problem: Basecamp and Mapsource don't show this map, GpsMapEdit shows a large white rectangle near 54.97743 -58.30292 I assume that we hit some unknown limit , possibly in LinePreparer or MapSplitter. I've also tried some older versions, so far they all show the problem. Any idea where to look? RgnDisplay shows this data for the problemat area: --------- Level 0, Subdiv 279 -------------------------------------------------- | | | final at 265f, (end 25e2) | | | polygon start 2634 to 265f 00002634 | 000000 | 4b | Polygon 1 | | | Type 0x4b 00002635 | 000001 | 00 00 00 | Label offset: 0x000000 () 00002638 | 000004 | d0 3b | Long delta 15312 0000263a | 000006 | 2a 3a | Lat delta 14890 | | | Start point 55.24913,-61.91139 2574796/-2885280 0000263c | 000008 | 0c | Bitstream length 12 0000263d | 000009 | bb | Base bb 0000263e | 00000a | 06 43 04 00 00 00 4c d1 | Bitstream (len: 12, 0xc) 00002646 | 000012 | 41 ef 00 00 | | | | xsame false, xneg false | | | ysame true, yneg true | | | xbase 16, ybase 15 | | | Coord 55.24913,-62.56851 2574796/-2915904 [-30624,+0] | | | Coord 54.61014,-62.56851 2545017/-2915904 [+0,-29779] | | | Coord 54.61014,-61.91139 2545017/-2885280 [+30624,+0] | | | 0 bits left, 0 | | | 0000264a | 000016 | 50 | Polygon 2 | | | Type 0x50 0000264b | 000017 | 00 00 00 | Label offset: 0x000000 () 0000264e | 00001a | d0 3b | Long delta 15312 00002650 | 00001c | b4 08 | Lat delta 2228 | | | Start point 54.97743,-61.91139 2562134/-2885280 00002652 | 00001e | 0b | Bitstream length 11 00002653 | 00001f | 9b | Base 9b 00002654 | 000020 | f2 8d 04 40 a7 fe d0 4b | Bitstream (len: 11, 0xb) 0000265c | 000028 | e7 00 00 | | | | xsame false, xneg false | | | ysame true, yneg false | | | xbase 16, ybase 11 | | | Coord 54.97743,-62.51706 2562134/-2913506 [-28226,+0] | | | Coord 55.01732,-62.54665 2563993/-2914885 [-1379,+1859] | | | Coord 55.01732,-61.91139 2563993/-2885280 [+29605,+0] | | | 4 bits left, 0 | | | Gerd

3 14

Commit r4701: fix possible empty rectangles : overSizePolyHole_v3.patch by Ticker Berkin
by svn commit 10 May '21

10 May '21

Version mkgmap-r4701 was committed by gerd on Mon, 10 May 2021 fix possible empty rectangles : overSizePolyHole_v3.patch by Ticker Berkin "A large multipolygon (larger than the maximum size for a level 1 subdiv) exists, and is broken into some similar size pieces and some smaller pieces to expose inners/holes. The same problem can be caused by any polygons having these size properties." http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4701

1 0