- mkgmap-dev - The mkgmap lists

Lost Waypoints with version 4589
by ael 21 Dec '20

21 Dec '20

Hello, I installed an 4589 map onto my Etrex 20, and all the Waypoints and routes were somehow deleted. The Waypointsxxx.gpx and other gpxfiles were still still present. As I have seen this problem before after updating firmware, I found that I could get the Etrek to re-read the Waypoint (and Route) gpx files by renaming them. There are more details on this blog post: https://hyperentang.wordpress.com/2018/04/16/lost-waypoints-on-garmin-etrek… Presumably there is something in the img file which is somehow altering the Waypoint status? Here are the commands that I used: java -Xmx10g -jar ../splitter-r597/splitter.jar ../great-britain-latest.osm.pbf Then I compiled the mapnik.txt from version 4589: java -Xmx13g -jar ../mkgmap-r4589/mkgmap.jar ../mkgmap-r4589/examples/typ-files/mapnik.txt Finally I compiled the img file with java -Xmx12g -jar ../mkgmap-r4589/mkgmap.jar --route --add-pois-to-areas --bounds=../bounds --precomp-sea=../sea/ --index --gmapsupp --remove-ovm-work-files mapnik.typ -c template.arg Did I do something wrong, or is this a known problem? ael

3 4

mkgmap-r4589 download
by Steph 16 Dec '20

16 Dec '20

Hi, Thank you for mkgmap-r4589 release. The archive is not available to download on the website. https://www.mkgmap.org.uk/download/mkgmap.html Regards Steph

3 2

arc direct heading
by Ticker Berkin 15 Dec '20

15 Dec '20

Hi Gerd In the October changes to arcs and headings I mistakenly removed a variable needed for setting reverse arc direct headings, ie half the route nodes had the wrong value. Routing mostly worked with this error but occasionally threw up strange decisions on my eTrex HCx. Patch attached - sorry about this. Ticker

2 1

Commit r4589: Fix wrong calculation of routing data (field reverse arc heading)
by svn commit 15 Dec '20

15 Dec '20

Version mkgmap-r4589 was committed by gerd on Tue, 15 Dec 2020 Fix wrong calculation of routing data (field reverse arc heading) arcDirectHeading.patch by Ticker Berkin "In the October changes to arcs and headings I mistakenly removed a variable needed for setting reverse arc direct headings, ie half the route nodes had the wrong value. Routing mostly worked with this error but occasionally threw up strange decisions on my eTrex HCx." http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4589

1 0

text updates mapnik.txt (TYP file)
by 7770 07 Dec '20

07 Dec '20

Hi. After some long time i had a chance to update also the points in the example mapnik.txt TYP file. I have added swedish descriptions to the extent possible (almost all). The file is attached, if you would like me to create some patch which you can easier check in, do let me know how i should create it. I have also noted a few cases (see further down) where the overall text is not matching the values in the descriptions. I have not changed them at this time. Regards Karl *Sized not matching:* [_point] type=0x006 subtype=0x00 ;GRMN_TYPE: Political Entities/CITY_200K/City with the range of* (200, 500] * thousand inhabitants/Non NT String=Small City / Large Town String1=0x01,Ville (*>50k)* String2=0x02,Stadt (50t) String4=0x03,Woonplaats (>50k) String6=0x07,Stad (> 50 t.) String7=0x15,Miasto (>50 tys.) String8=0x10,Cidade (>50k) String9=0x05,Città ExtendedLabels=Y FontStyle=LargeFont CustomColor=Day DaycustomColor:#414141 DayXpm="9 9 2 1" Colormode=16 "! c #737373" " c none" " !!!!! " " ! ! " "! !" "! !" "! !" "! !" "! !" " ! ! " " !!!!! " ;123456789 [end] *Hamlet is usually much smaller than 5000 inhabitants.* *Often as few as 100-200.* [_point] type=0x00b subtype=0x00 ;GRMN_TYPE: Political Entities/CITY_5K/City with the range of *(5, 10]* thousand inhabitants/Non NT String=Hamlet String1=0x01,Nom String2=0x02,Name String4=0x03,Naam String6=0x07,By String7=0x15,Nazwa String8=0x10,Nome String9=0x05,Borgo ExtendedLabels=Y FontStyle=SmallFont CustomColor=Day DaycustomColor:#737373 DayXpm="1 1 2 1" Colormode=16 "! c #00FF4B" " c none" " " ;1 [end] *Grocery store intended but many descriptions show bakery.* [_point] type=0x02e subtype=0x02 ;GRMN_TYPE: Business - Shopping/GROCERY_STORE/Grocery store/Non NT String=Grocery Store String1=0x01,Boulangerie String2=0x02,Bäckerei String4=0x03,Bakker String6=0x07,Livsmedelsaffär String7=0x15,Piekarnia String8=0x10,Padaria String9=0x05,Alimentari/Drogheria ExtendedLabels=Y FontStyle=NoLabel (invisible) CustomColor=No DayXpm="14 8 2 1" Colormode=16 "! c #BD30B4" " c none" " ! ! ! !! " " !! !! !! ! " " !! ! ! !! " "!!! !! !! !!!" "!!!!!!!!!!!!!!" "!!!!!!!!!!!!!!" "!!!!!!!!!!!!!!" " !!!!!!!!!!!! " ;12345678901234 [end] *What is this intended to be?* *An office, or a prison?* [_point] type=0x030 subtype=0x07 ;GRMN_TYPE: Business - Emergency and Government/GOV_OFFICE/Government Office/Non NT String=Government Office

2 1

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

TYP-object names showing as blank, what did i do wrong?
by 7770 29 Oct '20

29 Oct '20

Hi. I have an issue with TYP-object names showing as blank on a GPSMAP 66st instead of showing the names defined in the TYP file by the String=0xNN data. I tried loading the very same gmapsupp.img onto an old etrex vista hcx, it does show the defined default name (if i have english setup), or the next translation if i select any other language (it does not seem to be able to pair the languages). If i take [_line] objects as example. I have defined cycleway. The GPSMAP 66st does display the colour and drawing defined in the TYP file, but not the text if i hover over the line. Hovering over a line section that does not have a name, instead of saying "Cycleway" it shows nothing "". There are no errors when compiling the TYP file. If i take a compiled map from opentopomap, for some line which they have defined their own TYP, the device is showing the String for the same types which my map shows blank. It must be some error i have made, but what could it be? Regards Karl

2 2