- mkgmap-dev - The mkgmap lists

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

Road Number not showing in map
by Joao Almeida 22 Mar '24

22 Mar '24

Hi, I've recently compiled a map for Morroco. And found that I don't have the road number for some roads showing up. This is because I do not include the ref tag in the name. How can I create a logic in the style so that it shows the REF tag if there is no road name but if there is a road name can the name be displayed instead? Thank you!

2 2

Splitter Java Heap
by Felix Herwegh 21 Mar '24

21 Mar '24

Hi, switching to my Ultrabook (6 GB) while travelling I recently faced some kind of borderline condition with splitter. On the first run it throws "OutOfMemoryError: Java heap space", on closely subsequent runs without any modifications it does not. Repeating the task after some delay fails again. I guess, there might be some self-optimization involved for this. /fail: ... 40.000.000 ways parsed... id=888262666 Number of stored tile combinations in multiTileDictionary: 4.525 41.000.000 ways parsed... id=929920953 Exception in thread "main" java.lang.OutOfMemoryError: Java heap space at uk.me.parabola.splitter.tools.SparseLong2IntMap$ChunkMem.<init>(SparseLong2IntMap.java:189) at uk.me.parabola.splitter.tools.SparseLong2IntMap.saveCurrentChunk(SparseLong2IntMap.java:627) at uk.me.parabola.splitter.tools.SparseLong2IntMap.replaceCurrentChunk(SparseLong2IntMap.java:886) at uk.me.parabola.splitter.tools.SparseLong2IntMap.put(SparseLong2IntMap.java:691) at uk.me.parabola.splitter.SplitProcessor.processWay(SplitProcessor.java:149) at uk.me.parabola.splitter.AbstractMapProcessor.consume(AbstractMapProcessor.java:84) at uk.me.parabola.splitter.OSMFileHandler.execute(OSMFileHandler.java:157) at uk.me.parabola.splitter.Main.writeTiles(Main.java:542) at uk.me.parabola.splitter.Main.start(Main.java:132) at uk.me.parabola.splitter.Main.main(Main.java:81) Elapsed time: 8m 0s Memory: Current 1466MB (1339MB used, 127MB free) Max 1466MB/ /success: ... 48.000.000 ways parsed... id=1262369277 Writing relations Tue Mar 19 10:50:36 CET 2024 100.000 relations parsed... id=1783690 200.000 relations parsed... id=4148045 300.000 relations parsed... id=7895430 400.000 relations parsed... id=11681672 500.000 relations parsed... id=15581604 coord Map: 312.851.126 stored long/int pairs require ca. 3 bytes per pair. 14.225.657 chunks are used, the avg. number of values in one 64-chunk is 21. coord Map details: ~852 MB, including 88 array(s) with 8 MB way Map: 48.015.926 stored long/int pairs require ca. 3 bytes per pair. 3.974.651 chunks are used, the avg. number of values in one 64-chunk is 12. way Map details: ~123 MB, including 10 array(s) with 8 MB JVM Memory Info: Current 1466MB (1357MB used, 109MB free) Max 1466MB Full Node tests: 62.230.523 Quick Node tests: 282.354.912 Thread worker-2 has finished ... / My main machine has 24 GB of main memory, and runs troublefree using the following memory allocation on the same task: /JVM Memory Info: Current 3342MB (2378MB used, 964MB free) Max 6000MB/ Splitter 653 so far is involved without explicit memory allocation (java -jar .../splitter-latest/splitter.jar ...), using /java --version openjdk 11.0.22 2024-01-16 OpenJDK Runtime Environment (build 11.0.22+7-post-Debian-1deb10u1) OpenJDK 64-Bit Server VM (build 11.0.22+7-post-Debian-1deb10u1, mixed mode, sharing)/ Following up on splitter tuning hints (areas.list gets generated in each case) I reduced --max-areas= from 4096 to 2048 to 1024, but to no avail (not even significantly on the runtimes), once I figured out the effect above. It fails on all first runs and succeeds on all shortly following next ones. Unfortunately its not possible to increase main hardware memory on the small machine, but system tools report only about 2...3 GB being used anyway. Is it possible to tweak Java to overcome the problem without hurting the maps, preferably by machine, to be able to run identical scripts? Some pointers would be appreciated, also on how to monitor the Java memory situation. Thanks, Felix

2 3

Commit r4918: add surface=chipseal to group of surfaces which means paved
by svn commit 09 Mar '24

09 Mar '24

Version mkgmap-r4918 was committed by gerd on Wed, 06 Mar 2024 add surface=chipseal to group of surfaces which means paved Patch chipseal.diff by Carlos Dávila http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4918

3 4

Missing surface=chipseal in default style
by Carlos Dávila 06 Mar '24

06 Mar '24

Hello all One user of my maps has reported estrange detours in New Zealand. I have found the reason was the lack of a rule for surface=chipseal in default lines style, causing those roads to be considered as unpaved. Attached patch fixes the issue. Carlos

2 1

Commit r4917: fix typos in documentation: $LONG_DATE$ -> $LONGDATE$, $SHORT_DATE$ -> $SHORTDATE$
by svn commit 18 Feb '24

18 Feb '24

Version mkgmap-r4917 was committed by gerd on Sun, 18 Feb 2024 fix typos in documentation: $LONG_DATE$ -> $LONGDATE$, $SHORT_DATE$ -> $SHORTDATE$ http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4917

1 0

GRMN_TYPE
by brad 30 Jan '24

30 Jan '24

I was comparing a fairly new TYP file (r4905 mapnik.txt) with my own (grown from Openfietsmap quite a while ago) and noticed there was usually a line like this ;GRMN_TYPE: Roads/HIGH_SPEED_RAMP, RAMP/Highway ramp which is to be driven at high speeds/Non NT, NT or ;GRMN_TYPE: // What is the meaning of this? Thx Brad

2 3

Ranking of relations
by Bernard Mai 30 Jan '24

30 Jan '24

Dear all, I want to generate an overlay map to be used as additional layer on a Garmin watch. This layer can be turned on/off on the watch and should show only bicycle routes (route=bicycle and route=mtb). As most routes in openstreetmap are defined as relations I am using the following rules in my bike-routes style: *relations (file)* # Route relations as additional transparent layer for: # bicycle # mtb # bicycle routes type=route & route=bicycle { apply {set route='${route}';set route_name='$(route_name),${name}'|'${name}';set route_ref='$(route_ref),${ref}'|'${ref}';} } type=route & route=bicycle & network=icn {apply {set route_icn=yes;}} type=route & route=bicycle & network=ncn {apply {set route_ncn=yes;}} type=route & route=bicycle & network=rcn {apply {set route_rcn=yes;}} type=route & route=bicycle & network=lcn {apply {set route_lcn=yes;}} # mountainbike routes type=route & route=mtb { apply {set route='${route}'; set route_mtb_name='$(route_mtb_name),${name}'|'${name}'; set route_mtb_ref='$(route_mtb_ref),${ref}'|'${ref}';} } *lines (file)* # bicycle routes route=bicycle & route_icn=yes {name '${route_ref}'} [0x10f01 resolution 18-22 continue] route=bicycle & route_icn=yes {name '${route_name} (${route_ref})'|'${route_name}'|'${route_ref}'} [0x10f02 resolution 23-24] route=bicycle & route_ncn=yes [0x10f01 resolution 20-22 continue] route=bicycle & route_ncn=yes {name '${route_ref}'} [0x10f02 resolution 23 continue] route=bicycle & route_ncn=yes {name '${route_name} (${route_ref})'|'${route_name}'|'${route_ref}'} [0x10f02 resolution 24] route=bicycle & route_rcn=yes [0x10f03 resolution 20-22 continue] route=bicycle & route_rcn=yes {name '${route_ref}'} [0x10f04 resolution 23 continue] route=bicycle & route_rcn=yes {name '${route_name} (${route_ref})'|'${route_name}'|'${route_ref}'} [0x10f04 resolution 24] route=bicycle & route_lcn=yes {name '${route_name} (${route_ref})'|'${route_name}'|'${route_ref}'} [0x10f05 resolution 24] # mtb routes route=mtb {name '${route_mtb_ref}'} [0x10f06 resolution 23 continue] route=mtb {name '${route_mtb_name} (${route_mtb_ref})'|'${route_mtb_name}'|'${route_mtb_ref}'} [0x10f06 resolution 24] In general, these routes are drawn by mkgmap and I am able to generate an overlay map, but sometimes a route with "lower" priority (i. e. a route=mtb) hides a route with "higher" priority. In other words, I would like to show the routes in a ranking: The routes tagged with network=icn should be on top, followed by network=ncn and so on. The route=mtb should be only shown, if no other bicycle route is on the same way. Is this possible to achieve with mkgmap alone? Or do I need some sort of additional script to rank the relations before rendering them with mkgmap? I have read something, that the draw order depends on the ID of the relation and mkgmap renders the lower IDs first. But what about the higher relation IDs? It looks like ways tagged from the relation only get the tags from the relation with the lowest ID. Is this correct? Does anybody have an idea, how this could be overcome? Example: Way ID has 3 bicycle relevant relations: relation IDs 2119154, 9623717,2956920. With the style from above only the last one (relation ID 2956920, route=mtb) is shown although the second one (relation ID 9623717, network=icn) would be desired as it is an international bicycle route. Regards, Bernard

3 5

map types on different devices
by 7770 24 Jan '24

24 Jan '24

Hi. An observation, but maybe known to all mappers :-) I am using self defined TYP symbols for stay over huts or shelters along hiking trails or in the wilderness. It could be things like wildernes_hut lean_to shelter: https://wiki.openstreetmap.org/wiki/Tag%3Atourism%3Dwilderness_hut https://wiki.openstreetmap.org/wiki/Tag:shelter_type%3Dlean_to etc. For that i use the styles (points) to assign points in the group 0x2bnn (nn being a number). https://wiki.openstreetmap.org/wiki/OSM_Map_On_Garmin/ POI_Types#Type_0x2b_(Accommodation) According to the above page, eTrex devices may not show higher number than 0x2b07 in that group. What i notice is that GPSMAP 66s/st picks up higher values such as 0x2b11-0x2b18 and displays them, whereas eTrex 32x does not pick up those but i have to map the same symbols/icons to lower numbers (which not all are free). E.g., 0x2b07 works. I yet have to try exactly where the cut off is. Even if the eTrex 32x does not show the symbol on the map, at least some of the points can be searched for. If i have the map pointer close to the point and search for "all points" the points will show up in the list of close by points. But they do not show up under "lodging" category. Does anyone have additional details or guidance that i could read to see if i can find better numbers to assign so that the self made TYP definitions would show up on the etrex 32x device? Regards Karl

3 2