November 2020 - mkgmap-dev - The mkgmap lists

Please try branch check-precomp-sea
by Gerd Petermann 04 May '21

04 May '21

Hi all, I've implemented some basic checks to detect large flooded areas in the precomp-sea data in this new branch. A link to the latest binary (r4579 as of now) is a the bottom of the normal download page : http://www.mkgmap.org.uk/download/mkgmap.html - If PrecompSeaGenerator is used to calculate the sea data and the index check fails a warning is printed and the program ends with rc -1. - If mkgmap is used with a "dubious" sea.zip one or more messages about the problematic areas are written and the program stops with an ExitException unless option --x-check-precomp-sea=0 is given before the first input file. The index test is normally performed once for the whole planet, so it doesn't care about the actual tile boundaries. If e.g. only a part of Australia is flooded and you create a map for the UK you'll still see the errors. BTW: The current code (also in trunk version) doesn't support to use --precomp-sea with different values. Results are rather unpredictable. Gerd

4 4

Styles, typ and multiple languages
by 7770 31 Dec '20

31 Dec '20

Hi. I am looking into a pattern where a name of a map point is given in a local word, which is not easy for foreigners. Instead of showing the name as the name, i would like to move it into the information which becomes available when clicking on a point on a Garmin device. Hence leaving the name empty or removed. Example: Say we have a lean-to shelter somewhere in Sweden. The name is set as: "Vindskydd rastaplatsen". For any foreigner, this may not say a lot. Whereas in the TYP file it is defined with the description: .. String=Lean to shelter String6=0x07,Vindskydd String7=0x15,Schronienie String10=0x0f,Gapahuk etc. etc. .. So when pointing/hovering this object on the GPS unit, i will tell me in the local language (which is set up on the unit) what it is (taken from the TYP file). When clicking the item, i will get the info page with additional details, and here is the name. But the question is now: how do i get the additional details to the info page? Can i just add any tag an it will show? Would something like this work? tourism=lean_to | (amenity=shelter & shelter_type=lean_to) {add info = '$ {name}'; delete name} [0x2b05 resolution 24] Is it otherwise possible to define multiple name tags, one per language? name = general name name:en = English name name:se = Swedish name so that the device will pick up the correct one based on the language settings? Regards Karl

4 9

Unusual Routing Behaviour in BaseCamp
by Dave 16 Nov '20

16 Nov '20

Hi All, I have come across an unusual routing behaviour in BaseCamp on a stretch of road in Lusaka. When using the driving profile with no avoidances selected and the shorter distance route preference selected the route shown diverts down a link road and is obviously not the shortest route. Changing the route preference to faster time shows a more obvious route. Both route preferences should, in my opinion, be the same. See attached screen shots. After some investigations it would appear that this occurs when the -bounds option is used with bounds-latest.zip, if I do not use this option it routes as expected. The following are the commands used with mkgmap r4587: Routing problem: java.exe -jar C:\Users\Dave\Documents\Maps\Utils\mkgmap-r4587\mkgmap.jar ` --output-dir='C:\Users\Dave\Documents\Maps\Temp\Output' ` -c C:\Users\Dave\Documents\Maps\Options\Default.cfg ` -c C:\Users\Dave\Documents\Maps\Zambia\Split_Files\template.args ` The Default.cfg file has the following options: country-name="Zambia" area-name="Zambia" country-abbr="ZMB" overview-mapname=Zambia product-id=1 family-id=2526 draw-priority=20 max-jobs keep-going tdbfile order-by-decreasing-area gmapsupp bounds=C:\Users\Dave\Documents\Maps\Data\bounds-latest.zip latin1 index route remove-ovm-work-files nsis By commenting out the bounds option I change the routing behaviour. I have not used any typ or style files in case they were the cause of this. Also not tried on my Garmin device yet to see if the same behaviour occurs there as well. The routing error I have found occurs at this intersection but may occur elsewhere https://www.openstreetmap.org/#map=19/-15.45547/28.26647. After some experimentation this only happens when the adjoining way is tagged as a link road, in this case primary_link. Using JOSM I have changed the tag to secondary and later primary, saved the file to my laptop then processed the saved file and the unusual routing does not occur. Regards, Dave

3 7

Which options apply when.
by 7770 04 Nov '20

04 Nov '20

Hi. I am trying to understand how i can minimise the number of runs over the same data by running 1. splitter. 2. mkgmap to compile map tiles. 3. mkgmap to combine tiles into a gmapsupp.img file, possibly adding a TYP file. Say now that i want to create a few different maps from the same data. Splitting once looks fine for all cases. Applying styles (for lines, polygons, points) happens in step 2. But how about creating indices (--net, --index, --split-name-index, --road- name-config=filename)? Is that part of second step or can it be pushed to third step? Would it make any difference in processing time? How about using the same tiles, but applying different TYP to each created gmapsupp.img? Will that work well at step 3 given that different --mapname=name are set or will that not work well when placing multiple img files on the same device because something else is missing from an earlier step? It would be great if documentation could give some hints to when the various options are applied or when they can be best applied. Regards Karl

3 2

mapnik TYP, forest and wetland
by 7770 02 Nov '20

02 Nov '20

Hi. In the example mapnik.txt TYP file, the draworder of the polygons for woods/ forest 0x50 and wetland 0x51 are given like this: [_drawOrder] .. Type=0x050,3 .. Type=0x051,2 .. [End] When compiling a map, this means that wetlands in forests are not visible if this TYP is used. I tried makling a map using the same draworder Type=0x050,2 Type=0x051,2 plus using the option --order-by-decreasing-area This makes the wetland visible in forests. I could not see any negative impacts of this in the areas which i checked (a few in Sweden and Norway). Wetlands over other areas seems to work fine as well. Do you think such a change would be of help or is there a great risk that this type of change would impact negatively on the drawing of the maps? Regards Karl

3 7

TYP file. Descriptions and translations
by 7770 02 Nov '20

02 Nov '20

Hi. I am working my way through adding swedish translations to as many types as possible in the mapnik.txt file. Currently i am done with the polygons. Aside from adding swedish i observe a few things which may be incorrect named. Numbered but in no particular order. The attached file does also contains a few in polish translations, those are mentioned here, and also included in the file. 1. The style: leisure=water_park [0x09 resolution 21] has the TYP: [_polygon] type=0x09 ;GRMN_TYPE: Large Manmade Areas/MARINA/Marina area/Non NT String=Marina String1=0x01,Piscine String2=0x02,Schwimmbad String3=0x04,Water Park String4=0x03,Zwembad String7=0x15,Basen String8=0x10,Piscina String9=0x05,Piscina ... For me a marina is very different from a water park. In this case i tend to say that the mapping in the style polygons file is questionable. Perhaps it should be: leisure=marina [0x09 resolution 21], or both marina and water_park. As for the names in the TYP file, the english name indicates marina, but all others indicate Swimming pools, bath. 2. Possible incorrect translations. [_polygon] type=0x12 ;GRMN_TYPE: // String=Retail String1=0x01,Aire String2=0x02,Raststätte String4=0x03,Snelweg rustplaats ExtendedLabels=Y FontStyle=NoLabel (invisible) CustomColor=No Xpm="0 0 1 0" "1 c #EFC8C8" [end] I think it is because two rules in the styles map to this type. highway=services [0x12 resolution 22] # service station complex;.. landuse=retail [0x12 resolution 20-23] It looks like the English speaker has thought of a retail area (landuse=retail) whereas the others thought more of highway=services Compare with: https://wiki.openstreetmap.org/wiki/Map_Features Landuse section. I cant give a good idea what would be the best way to resolve this, perhaps map differently? 3. All strings have String1 (should work, just bad looking). [_polygon] type=0x25 ;GRMN_TYPE: // ;See also 0x6b for pedestrian area String=Square String1=0x01,Place String1=0x02,Platz String1=0x03,Markt String1=0x05,Piazza String1=0x08,Plaza ExtendedLabels=Y FontStyle=NoLabel (invisible) CustomColor=No Xpm="0 0 1 0" "1 c #DDDDE8" [end] 4. Polish translation updated (0x15). [_polygon] type=0x46 ;GRMN_TYPE: Water Areas/LARGE_RIVER/Major river, typically at least 700 ft in width/Non NT String=River String1=0x01,Eau String2=0x02,Wasser String4=0x03,Water String7=0x15,Rzeka String8=0x10,Água String9=0x05,Acqua ExtendedLabels=Y FontStyle=NoLabel (invisible) CustomColor=No Xpm="0 0 1 0" "1 c #AAD3DF" [end] 5. Polish translation updated.(0x15). [_polygon] type=0x47 ;GRMN_TYPE: Water Areas/RIVER_GT_700FT/Major river greater or equal to 700 ft in width/Non NT String=Waterfall String1=0x01,Eau String2=0x02,Wasser String4=0x03,Water String7=0x15,Wodospad String8=0x10,Água String9=0x05,Acqua ExtendedLabels=Y FontStyle=SmallFont CustomColor=Day DaycustomColor:#4D80B3 Xpm="0 0 1 0" "1 c #AAD3DF" [end] 6. Polish translation updated (0x15). [_polygon] type=0x48 ;GRMN_TYPE: Water Areas/RIVER_100FT, SMALL_RIVER/Minor river, typically less than 700 ft in width/Non NT String=Canal String1=0x01,Eau String2=0x02,Wasser String4=0x03,Water String7=0x15,Kanał String8=0x10,Água String9=0x05,Acqua ExtendedLabels=Y FontStyle=SmallFont CustomColor=Day DaycustomColor:#4D80B3 Xpm="0 0 1 0" "1 c #AAD3DF" [end] 7. Polish translation updated (0x15) [_polygon] type=0x4b ;GRMN_TYPE: Map Bounds/DATA_BOUNDS/Bounds of map after creation/Non NT String=Area of Map Coverage String1=0x01,Sol String2=0x02,Hintergrund String4=0x03,Achtergrond String7=0x15,Tle String8=0x10,Área não mapeada String9=0x05,Sfondo ExtendedLabels=Y FontStyle=LargeFont CustomColor=Day DaycustomColor:#00FFFF Xpm="0 0 1 0" "1 c #F2EFE9" [end] 8. Polish translation updated (0x15) [_polygon] type=0x4f ;GRMN_TYPE: Surface Cover Areas/SCRUB/Scrub brush area/Non NT String=Scrub String1=0x01,Broussailles String2=0x02,Gebüsch String4=0x03,Kreupelbos String7=0x15,Zarośla / Nieużytki ... Regards Karl

5 11