- mkgmap-dev - The mkgmap lists

documentation improvement
by Mike Baggaley 09 Apr '20

09 Apr '20

Hi Gerd, please find attached a small patch that improves the documentation primarily for the following, but with a few other minor tweaks: removal of the statement about putting --description after -c template.args, as this incorrect simplification of the description of --style-file as this was confusing clarification that the number of bytes are the file sizes in the Hill Shading section I note that the '' symbols used to denote arcseconds are being interpreted as italic identifiers <i></i> by whatever process produces the web page. I suggest this process needs to be changed so that this does not happen. I have replaced the first mentions of '' with words. If the process cannot easily be changed, I suggest that the remaining '' symbols are replaced with arc second or arc seconds. I also note that the --dem-dists mentions that values should be a multiple or submultiple of 3314 or 9942 then goes on to suggest values that are multiples of 3312, which I believe is the nearest value to 3314 that is a multiple of 16. I think the explanation needs some improvement by someone who knows exactly how it works. I have been experimenting with various values of --dem-dists - the default value of 9936 works fine for me at higher resolutions in Basecamp, but becomes very blocky at low resolution. I find --dem-dists=9936,9936,9936,9936,9936,9936,39744,317952 gives the best results for my levels of 0:24,1:22,2:21,3:20,4:19,5:18,6:17,7:15. Based on this, I'd be very surprised if the example in the documentation of --dem-dists=3312,13248,26512,53024 for levels 0:24, 1:22, 2:20, 3:18 gives decent results at resolution 18. However, not having any 1 arc second DEM data, I can't try it. Regards, Mike

5 18

Commit r4479: improve documentation: options4.txt.patch by Mike Baggaley
by svn commit 09 Apr '20

09 Apr '20

Version mkgmap-r4479 was committed by gerd on Thu, 09 Apr 2020 improve documentation: options4.txt.patch by Mike Baggaley http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4479

1 0

Default Style - dead conditions?
by nwillink 08 Apr '20

08 Apr '20

Hi Ticker Looking at you style file I noticed that there might be an issue with the following (In fact it is found in the default style) 145 highway=motorway [0x01 road_class=4 road_speed=7 resolution 15] 277 (highway=motorway | highway=trunk) & ref=*{name '${ref|highway-symbol:hbox}'; addlabel '${name}'} Under which condition will highway=motorway be TRUE in line 277 Are we missing a 'continue' ? ie highway=motorway [0x01 road_class=4 road_speed=7 resolution 15 continue] (Same applies for primary& secondary) 155 highway=primary [0x03 road_class=3 road_speed=4 resolution 19] 278 highway=primary & ref=*{name '${ref|highway-symbol:box}' ; addlabel '${name}'} 161 highway=secondary [0x04 road_class=2 road_speed=3 resolution 20] 279 (highway=secondary | highway=tertiary) & ref=*{name '${ref|highway-symbol:oval}'; addlabel '${name}'} Regards Nick -- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html

2 1

Blue background with Oregons, what whas the solution?
by Thorsten Kukuk 08 Apr '20

08 Apr '20

Hi, I'm pretty sure that I did read the discussion here, but cannot find it anywhere again. On some Garmin devices (newer Oregons, e.g.) parts of the background of the map is shown as blue "sea", not with the normal background. Does anybody remember what the problem was and how to fix that? Since I don't own any of this devices who show it "wrong", I cannot test it myself. Thanks, Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg)

4 4

How to make a scale-dependent TYP style?
by Niccolo Rigacci 08 Apr '20

08 Apr '20

Hi to all, I'm trying to create a map for an old eTrex 10 Garmin device. Everything works fine, but I don't understand how to make a custom TYP file that will render roads differently at different scales. This is my mkgmap invokation: mkgmap \ --reduce-point-density=4 --unicode \ --description="$DESCRIPTION" \ --style-file='./styles/default/' \ --country-name='Italy' --country-abbr='I' \ --region-name='Toscana' \ --family-id=9999 \ --gmapsupp 63240*.osm.pbf \ ./typ/my_etrex10.txt as you can see I have customized the default style and I have provided a custom TYP file to override only _line Type=0x006 and Type=0x016 rendering. My style defines four levels: levels = 0:24, 1:20, 2:19, 3:18 The problem is that my custom TYPs are applied the same at any level (scale), whereas the default TYP are scale-dependant (e.g. secondary roads are rendered gradually thicker when zooming in). This is my TYP file, indeed there are no scale-dependant rules! Am I missing something in the TYP syntax? [_line] Type=0x006 ;GRMN_TYPE: UseOrientation=Y LineWidth=2 BorderWidth=0 Xpm="0 0 2 0" "1 c #BD9541" "2 c #000000" String1=0x04,Way ExtendedLabels=N [end] [_line] Type=0x016 ;GRMN_TYPE: Roads/TRAIL/Walkway or trail/Non NT, NT UseOrientation=Y Xpm="32 1 2 1" "! c #808080" " c none" "!!!! !!!! !!!! !!!! !!!! !!" ;12345678901234567890123456789012 String1=0x04,Path ExtendedLabels=N [end] -- Niccolo Rigacci - http://www.rigacci.net/ Campi Bisenzio - Firenze - Italy Tel. Mobile: +39-327-5619352

4 7

Commit r4478: - add range check for --family-id, value must be in the range 1..65535, not 1..9999
by svn commit 07 Apr '20

07 Apr '20

Version mkgmap-r4478 was committed by gerd on Tue, 07 Apr 2020 - add range check for --family-id, value must be in the range 1..65535, not 1..9999 - document the larger range http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4478

1 0

missing check for option --family-id
by Gerd Petermann 07 Apr '20

07 Apr '20

Hi all, in the garmin forum there is a discussion about the range : https://forum.openstreetmap.org/viewtopic.php?pid=782395#p782395 The current options.txt says --family-id=integer This is an integer that identifies a family of products. Range: [1..9999] Default: 6324 This limit is neither checked nor is it correct. The corresponding value is stored in a two byte field and most mkgmap sources interpret it as a 16-bit-unsigned integer. However, in class uk.me.parabola.tdbfmt.HeaderBlock the field is stored in a short (signed 16-bit-int). My conclusion: We should print a warning when the value given in --family-id is < 0 or > 32767. Gerd

4 3

subst only numbers
by Arndt Röhrig 05 Apr '20

05 Apr '20

3 3

North Arrow on Garmin Devices
by Pitney 03 Apr '20

03 Apr '20

Hello Displayed on my Garmin devices with maps made with mkgmap is a North arrow that is beige in color. Not highly visible and I use the North arrow allot. I want to change this to a red arrow so that it is more visible. Is this possible via the .typ file or is this a firmware setting? I have searched but it seems I am the only one interested in this change. Thanks Pitney

3 2

cities*.zip extract error
by Steph 03 Apr '20

03 Apr '20

Hi, Have you got an error extracting cities*.zip files from http://download.geonames.org/export/dump/ since today ? $ unzip cities15000.zip Archive: cities15000.zip End-of-central-directory signature not found. Either this file is not a zipfile, or it constitutes one disk of a multi-part archive. In the latter case the central directory and zipfile comment will be found on the last disk(s) of this archive. unzip: cannot find zipfile directory in one of cities15000.zip or cities15000.zip.zip, and cannot find cities15000.zip.ZIP, period. So java (splitter) crash on this file… 😟 Regards Steph

3 2