June 2020 - mkgmap-dev - The mkgmap lists

Fwd: Re: "Small" SRTM1 files and DEM maps
by Carlos Dávila 05 Oct '20

05 Oct '20

Hi Gerd I replied to your patch a couple of months ago, but I have now realized it didn't arrive to the list (it seems I used and old address). I was surprised you didn't say anything, but didn't want to bother... I used your binary for my test. Today I have tried to apply your patch, but it seems to be generated against a different version of files in trunk. -------- Mensaje reenviado -------- Asunto: Re: [mkgmap-dev] "Small" SRTM1 files and DEM maps Fecha: Tue, 21 Apr 2020 17:38:19 +0200 De: Carlos Dávila <cdavilam(a)orangecorreo.es> Para: mkgmap-dev(a)lists.mkgmap.org.uk Hi Gerd I have tested it in an area of 4x10 degrees, in the North of China, and it worked fine. El 21/4/20 a las 14:40, Gerd Petermann escribió: > Hi Carlos, > > please try the attached patch or this binary based on r4483: > http://files.mkgmap.org.uk/download/468/mkgmap.jar > I hope I found all the places that need to be changed. I've only > tested with a map around the point N50 E118. > > Gerd > > ________________________________________ > Von: mkgmap-dev <mkgmap-dev-bounces(a)lists.mkgmap.org.uk> im Auftrag > von Carlos Dávila <carlos(a)alternativaslibres.org> > Gesendet: Dienstag, 21. April 2020 11:27 > An: mkgmap-dev(a)lists.mkgmap.org.uk > Betreff: Re: [mkgmap-dev] "Small" SRTM1 files and DEM maps > > Great new!! Thanks for your support > > El 21/4/20 a las 11:19, Gerd Petermann escribió: >> Hi Carlos, >> >> yes, I see that the source code handles this format. I finally found >> https://dds.cr.usgs.gov/srtm/version2_1/Documentation/MIL-PDF-89020B.pdf >> I think "TABLE I. Matrix intervals for DTED Level 0." >> shows how to interpret the data. It seems there are a few more >> variants... >> For now I'll try to support also the 1801 * 3601 * 2 format >> >> Gerd >> >> ________________________________________ >> Von: mkgmap-dev <mkgmap-dev-bounces(a)lists.mkgmap.org.uk> im Auftrag >> von Carlos Dávila <carlos(a)alternativaslibres.org> >> Gesendet: Donnerstag, 16. April 2020 17:41 >> An: mkgmap-dev(a)lists.mkgmap.org.uk >> Betreff: Re: [mkgmap-dev] "Small" SRTM1 files and DEM maps >> >> HI Gerd >> I don't think conversion is wrong. If input geotiff file is 24MB, output >> hgt file is 24 MB, if input tiff is 12MB, output hgt is 12MB >> I use this command on Linux: >> for i in *.tif ; do gdal_translate -strict -q -eco -of SRTMHGT $i >> `basename $i tif`hgt ; done ; rm -f *.hgt.aux.xml >> BTW, gdal is also able to deal with small SRTM files >> >> El 16/4/20 a las 11:31, Gerd Petermann escribió: >>> Hi Carlos, >>> >>> so your conversion routine is wrong. The file size is 12.970.802 >>> bytes. There is no integer n for which 2 * n^2 results in this value. >>> >>> Gerd >>> >>> ________________________________________ >>> Von: mkgmap-dev <mkgmap-dev-bounces(a)lists.mkgmap.org.uk> im Auftrag >>> von Carlos Dávila <cdavilam(a)orangecorreo.es> >>> Gesendet: Donnerstag, 16. April 2020 11:19 >>> An: mkgmap-dev(a)lists.mkgmap.org.uk >>> Betreff: Re: [mkgmap-dev] "Small" SRTM1 files and DEM maps >>> >>> Hi Gerd >>> Forgot to mention files are downloaded as geotiff, but I then convert >>> them to hgt, sorry. >>> You can download a sample one from >>> https://alternativaslibres.org/tmp/N50E118.hgt >>> >>> El 16/4/20 a las 9:18, Gerd Petermann escribió: >>>> Hi Carlos, >>>> >>>> are you talking about geotiff format? I think someone documented >>>> how that format can be converted to *.hgt. >>>> Can you post a link to such a file? >>>> >>>> Gerd >>>> >>>> >>>> >>>> ________________________________________ >>>> Von: mkgmap-dev <mkgmap-dev-bounces(a)lists.mkgmap.org.uk> im Auftrag >>>> von Carlos Dávila <cdavilam(a)orangecorreo.es> >>>> Gesendet: Montag, 13. April 2020 14:08 >>>> An: mkgmap-dev(a)lists.mkgmap.org.uk >>>> Betreff: Re: [mkgmap-dev] "Small" SRTM1 files and DEM maps >>>> >>>> Hi Gerd >>>> They are downloaded by phyghtmap. This is what I found digging into >>>> phyghtmap files: >>>> |def getSRTMFileServer(self, resolution, srtmVersion):|| >>>> || if srtmVersion == 2.1:|| >>>> || return >>>> "https://dds.cr.usgs.gov/srtm/version2_1/SRTM{0:d}".format(resolution)|| >>>> || elif srtmVersion == 3.0:|| >>>> || if resolution == 1:|| >>>> || urlRe = >>>> "https://earthexplorer.usgs.gov/download/8360/SRTM1{:s}V3/GEOTIFF/EE"|| >>>> || elif resolution == 3:|| >>>> || urlRe = >>>> "https://earthexplorer.usgs.gov/download/4960/SRTM3{:s}V2/GEOTIFF3/EE"|| >>>> || return urlRe| >>>> They should come from the second URL above. >>>> >>>> El 13/4/20 a las 8:24, Gerd Petermann escribió: >>>>> Hi Carlos, >>>>> >>>>> sorry for the late response. I found no hint on the phyghtmap page >>>>> http://katze.tfiu.de/projects/phyghtmap/ >>>>> regarding a new format for srtm data. The hgt format is not >>>>> compressed. Do you know from where these 12.4 MB files came from? >>>>> >>>>> Gerd >>>>> >>>>> ________________________________________ >>>>> Von: mkgmap-dev <mkgmap-dev-bounces(a)lists.mkgmap.org.uk> im >>>>> Auftrag von Carlos Dávila <cdavilam(a)orangecorreo.es> >>>>> Gesendet: Samstag, 11. April 2020 17:09 >>>>> An: Development list for mkgmap >>>>> Betreff: [mkgmap-dev] "Small" SRTM1 files and DEM maps >>>>> >>>>> I use phyghtmap to build contour lines and also to download hgt data >>>>> that I then use to build DEM maps with mkgmap. For a long time, SRTM1 >>>>> files (and also VFP1) have all been ~24.7 MB in size, but lately (I >>>>> don't remember since when) SRTM1 are also served as 12.4 MB files. >>>>> phyghtmap is able to generate contour lines from those small files, as >>>>> they seem to contain the same information but with a different >>>>> compression ratio, but mkgmap fails to read them, and report them as >>>>> missing. Would it be possible to get support for such files in mkgmap? >>>>> _______________________________________________ >>>>> mkgmap-dev mailing list >>>>> mkgmap-dev(a)lists.mkgmap.org.uk >>>>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >>>>> _______________________________________________ >

2 2

Performance of POI search on the Device
by franco_bez 28 Jul '20

28 Jul '20

Hi all, searching for POIs on my Oregon often is very frustrating. It virtually takes forever. Yesterday I noticed that some POI types are reasonably fast, while others are 10 times slower. I assume that this is some sort of index Problem. For example using my DACH map, built with mkgmap-r4506, map size 2.7GiB on my Oregon 750t - searching for Gas Stations takes some 5 seconds - searching for Bank/ATM takes some 50 seconds - searching for Any-/All Poi types also takes some 50 seconds for the first Elements to appear in the list. If I can trust my memory, in the past, maybe some 2 years ago, searching for Gas Stations was just as slow as any other POI type. What can I do to get the POI search fast for any POI type in the map ? I tried --make-poi-index but this didn't make any noticeable difference. Ciao, Franco -- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html

4 22

Re: [mkgmap-dev] Misc documentation fixes
by Ticker Berkin 09 Jul '20

09 Jul '20

Hi Eugene 1. Sorry about that - I missed making the changes to mapnik.txt 2. Should be: Example usage: --mdr7-excl="Road, Street, Weg" but --x-mdr7-excl=... will work I'll fix these some time soon, but if mapnik.txt is causing you problems, I've provided a patch or you can edit the file with a text editor. Regards Ticker On Mon, 2020-06-22 at 09:42 -0700, eugeny_burynin(a)mail.ru wrote: > Hi Ticker > > Thanks so much for fixing the problem. > > There are two more questions. > 1. Changes to the points file were made to revision 4526, but these > changes were not made to the mapnik.txt file. As a result, a mismatch > occurred. > - Change the typCode of motorway junction from 0x2100 (Exit with > Services) to 0x2000 (Exit without Services) and only do if exit: > road_ref is set. Also attempt to set exit: to from standard OSM tags > exit_to or destination. > - Change the typCode of services from 0x210f (see above) to 0x230f > (Exit Service Area), do even if generated from polygon, set some > facilities and show at a lower resolution. > > 2. In the options.txt file in the description > --mdr7-excl = name [, name ...] > Specify words which should be omitted from the road index. It was > added > before option road-name-config and is probably no longer needed. > Example usage: --x-mdr7-excl = "Road, Street, Weg" > How to - mdr7-excl = name or --x-mdr7-excl = name > > Sorry for my English, this is Google translator. > > Regards, Eugene > > <quote author='Ticker Berkin'> > Hi Eugene > > I see. > > This is part of an automatic system that builds the release zip and > web > documentation when updates are committed to the svn repository. Parts > of the release zip doc directory build are failing, but the web > update > of the same information are happening correctly > > I'll try and find out more. > > Regards > Ticker > > > On Sat, 2020-06-20 at 22:47 -0700, eugeny_burynin(a)mail.ru wrote: > > Sorry for my English, this is Google translator. > > > > See the end of the file > > http://www.mkgmap.org.uk/download/mkgmap-r455 > > 3.zip\mkgmap-r4553\doc\typ-compiler.txt > > Polygon elements trimmed, missing Line elements, Points (POI), > > Icons > > > > Regards, Eugene > > > > <quote author='Ticker Berkin'> > > Hi Eugene > > > > Yes - You're right, they are different. > > > > I hadn't noticed before, but the the versions of the files in > > release > > download have been through a document processor. This is "asciidoc" > > in > > the case of the style manual, but I'm not sure about the others. > > > > Whatever it is, it fails for "tuning.txt", but the others look > > reasonably like the resultant versions available from > > > > http://www.mkgmap.org.uk/doc/index.html > > > > Ticker > > > > On Sat, 2020-06-20 at 08:11 -0700, eugeny_burynin(a)mail.ru wrote: > > > Thank you for your work. > > > > > > But compilation doesn't work correctly. > > > I compare the documentation files located in the archive > > > http://www.mkgmap.org.uk/download/mkgmap-r4553.zip > > > http://www.mkgmap.org.uk/download/mkgmap-r4553.zip\mkgmap-r4553\d > > > oc > > > \i > > > ndex.txt > > > http://www.mkgmap.org.uk/download/mkgmap-r4553.zip\mkgmap-r4553\d > > > oc > > > \t > > > uning.txt > > > http://www.mkgmap.org.uk/download/mkgmap-r4553.zip\mkgmap-r4553\d > > > oc > > > \t > > > yp-compiler.txt > > > with files of the same name located > > > http://www.mkgmap.org.uk/websvn/l > > > isting.php?repname=mkgmap&path=%2Ftrunk%2Fdoc%2F&rev=4553&peg=455 > > > 3# > > > a2 > > > 008cef70b23f59cfd5d9cad5e05e6c8 > > > > > > They don't match. > > > > > > Sincerely, Eugene > > > > > > <quote author='Ticker Berkin'> > > > Hi Gerd > > > > > > I didn't get the layout of one of my typ-compiler changes correct > > > for > > > when it appears here: > > > > > > http://www.mkgmap.org.uk/doc/typ-compiler > > > > > > so I've had another go - I'm still guessing at how the layout > > > language > > > works. > > > > > > Also fixed another couple of trivial noticed when comparing > > > resultant > > > page with: > > > > > > https://wiki.openstreetmap.org/wiki/Mkgmap/help/typ_compile > > > > > > Minor patch attached. > > > > > > Ticker > > > > > > > > > _______________________________________________ > > > mkgmap-dev mailing list > > > mkgmap-dev(a)lists.mkgmap.org.uk > > > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > > > > miscDoc_v3.patch (2K) > > > <http://gis.19327.n8.nabble.com/attachment/5968878/0/miscDoc_v3.p > > > at > > > ch > > > > > > > > > > </quote> > > > Quoted from: > > > http://gis.19327.n8.nabble.com/Misc-documentation-fixes-tp5968452 > > > p5 > > > 96 > > > 8878.html > > > > > > > > > _____________________________________ > > > Sent from http://gis.19327.n8.nabble.com > > > > > _______________________________________________ > > mkgmap-dev mailing list > > mkgmap-dev(a)lists.mkgmap.org.uk > > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > > </quote> > > Quoted from: > > http://gis.19327.n8.nabble.com/Misc-documentation-fixes-tp5968452p5 > > 96 > > 8902.html > > > > > > _____________________________________ > > Sent from http://gis.19327.n8.nabble.com > > > _______________________________________________ > mkgmap-dev mailing list > mkgmap-dev(a)lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > </quote> > Quoted from: > http://gis.19327.n8.nabble.com/Misc-documentation-fixes-tp5968452p596 > 9028.html > > > _____________________________________ > Sent from http://gis.19327.n8.nabble.com >

1 1

Routing problem on Garmin Oregon/edge with default style (and other styles)
by Felix Hartmann 08 Jul '20

08 Jul '20

https://www.openstreetmap.org/way/27866666/history#map=15/40.4752/-3.9411 Trying to route along this route crashes the GPS device - not sure what i going on here. In demo mode - just set location to: https://www.openstreetmap.org/way/27866666/history#map=18/40.48063/-3.94040 and route to: https://www.openstreetmap.org/way/27866666/history#map=19/40.46711/-3.94385 (Calle Castillo de Ponferrada) The route will first be normal pink, however as soon as it goes onto the Calle Castillo de Alarcón it will keep on routing - but the pink colour is gone. Then after maybe half of the road it stops routing and asks to recalculate (which will be in a loop if you click yes). map produced with. start /low /b /wait java -jar -XX:+AggressiveHeap -XX:StringTableSize=1000003 -Xms15000M -Xmx29000M C:\openmtbmap\mkgmap.jar --max-jobs=8 --order-by-decreasing-area --code-page=1252 --add-boundary-nodes-at-admin-boundaries --nsis --index --levels="0:24, 1:23, 2:22, 3:21, 4:20, 5:19, 6:18" --overview-levels="7:17, 8:16, 9:15, 10:14, 11:13, 12:12" --add-pois-to-areas --pois-to-areas-placement=entrance=main;entrance=yes;building=entrance;barrier=entrance --reduce-point-density=3.4 --reduce-point-density-polygon=6 --add-boundary-nodes-at-admin-boundaries=2 --poi-excl-index=0x6405,0x4316,0x2f00 --cycle-map --check-roundabout-flares --ignore-fixme-values --housenumbers --road-name-config=C:\openmtbmap\openmtbmap_svn\roadNameConfig.txt --split-name-index --link-pois-to-ways --ignore-turn-restrictions --polygon-size-limits="24:16, 23:14, 22:12, 21:11, 20:10, 19:9, 18:8, 17:7, 16:6, 15:5, 14:4, 13:3, 12:2, 11:0, 10:0" --description=omtb_es --show-profiles=1 --location-autofill=bounds,is_in,nearest --route --country-abbr=es --country-name=spain --mapname=64130000 --family-id=6413 --product-id=1 --series-name=omtb_spain_26.06.2020 --family-name=mtb_es_26.06.2020 --tdbfile --overview-mapname=mapsetc --keep-going --area-name="spain_26.06.2020_omtb" D:\openmtbmap\maps\64130028.osm.pbf 1>NUL 2>NUL Routing setup on device as: ATV/Off Road Driving Minimize Distance No Avoidances but I think this does not matter. I have uploaded the broken tile/map here: https://openmtbmap.org/maps.7z the osm.pbf for that tile is: https://openmtbmap.org/64130028.osm.pbf I have no real clue what is happening here. If you set highway=residential from road_class=0 / road_speed=2 to say 1 / 1 crash is even earlier. I cannot find anything special looking at the road with GPSMapedit. Garmin Edge devices supposedly crash too - not sure about other devices. Felix

9 47

CodePage number set to 0 after compiled
by Manfred Haiduk 05 Jul '20

05 Jul '20

Hi all, i don't know, if i had something forgotten but since some time, if i compile my style.txt with mkgmap, the resulting typ-file seems to not have any codepage number other than Zero. Only the TYPviewer complains about this, on my device (GPSMAP 476cx) or with MapSource i don't see any troubles. This is the error message the TYPviewer generates : ****************************************************************************************************************************************************** Errors in the file : D:\GPS\Maps\MYGERMANY\newstyle.typ ****************************************************************************************************************************************************** Unknown CodePage number: 0 TYPViewer has replaced it with 1252 If it doesn't fit, select an another CodePage number in the combobox "CodePage" Any ideas what to do ? btw i used mkgmap-r4487 to compile

5 7

mapnik typ file and barrier=wall
by Gerd Petermann 29 Jun '20

29 Jun '20

Hi TYP experts, it seems that line type 0x17 (barrier=wall) is not visible in Basecamp? Gerd

6 8

minor documentation improvement
by Mike Baggaley 27 Jun '20

27 Jun '20

Hi Gerd, please find attached a patch for a minor change to the documentation: Removal of mention of --no-net which does not appear to exist in the code Moving of --max-flare-length-ratio to immediately after the related --check-roundabout-flares option Minor improvement of text in the --precomp-sea section Cheers, Mike

1 0

Re: [mkgmap-dev] mkgmap-dev Digest, Vol 143, Issue 54
by John Thorn 24 Jun '20

24 Jun '20

Just a thought.... Is it a case of too many tiles on the device? Most devices have a limit on the number of tiles across all installed maps. Often c4000. John On Mon, 15 Jun 2020 at 13:09, <mkgmap-dev-request(a)lists.mkgmap.org.uk> wrote: > Send mkgmap-dev mailing list submissions to > mkgmap-dev(a)lists.mkgmap.org.uk > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > or, via email, send a message with subject or body 'help' to > mkgmap-dev-request(a)lists.mkgmap.org.uk > > You can reach the person managing the list at > mkgmap-dev-owner(a)lists.mkgmap.org.uk > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of mkgmap-dev digest..." > Today's Topics: > > 1. Re: Tiles missing (Joris Bo) > 2. Re: Tiles missing (Pierre Brico) > > > > ---------- Forwarded message ---------- > From: Joris Bo <jorisbo(a)hotmail.com> > To: Development list for mkgmap <mkgmap-dev(a)lists.mkgmap.org.uk> > Cc: > Bcc: > Date: Mon, 15 Jun 2020 11:39:50 +0000 > Subject: Re: [mkgmap-dev] Tiles missing > > Hi Brico, > > > > Does your newly created map displays in basecamp correctly? > > If no: The start is to find out why tiles are skipped by mkgmap or > splitter by investigating the error logging (This is the tip of Ticker) > > If yes: A start could be to disable all maps on your device by renaming > the *.IMG extension to *._IMG except your own map. > > You can find the maps on both the device as the SSD in the map garmin > > > > If you created the maps the most straight forward way (without specifying > family id and tile number start for example) you can easily create > duplicate tile numbers which could conflict with other mapmakers. Default > all tiles start with 6324xxx1 > > > > > > > > *Van:* mkgmap-dev <mkgmap-dev-bounces(a)lists.mkgmap.org.uk> *Namens *Pierre > Brico > *Verzonden:* zondag 14 juni 2020 18:16 > *Aan:* Development list for mkgmap <mkgmap-dev(a)lists.mkgmap.org.uk> > *Onderwerp:* Re: [mkgmap-dev] Tiles missing > > > > > > Yes, my GPSMAP 66s runs the latest firmware (4.20 see > https://www8.garmin.com/support/download_details.jsp?id=14337) > > > > Note that the France OpenTopoMap on the same device is working properly. > > > > I can also try the map on my 64s if this can help to identify the > problem... > > > > > > On Sun, Jun 14, 2020 at 3:46 PM Ralf Kleineisel <ralf(a)kleineisel.de> > wrote: > > Hi, > > Am 13.06.20 um 11:41 schrieb Pierre Brico: > > > A few months ago, I bought a Garmin GPSMAP 66s (I've already other > > > Now I would like to generate a map for my next holiday in France but I > > have issues with missing tiles. > > does your device run the latest firmware? I had weird display problems > with older firmware on my 64s. > > > > _______________________________________________ > mkgmap-dev mailing list > mkgmap-dev(a)lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > > > ---------- Forwarded message ---------- > From: Pierre Brico <pierre.brico(a)gmail.com> > To: Development list for mkgmap <mkgmap-dev(a)lists.mkgmap.org.uk> > Cc: > Bcc: > Date: Mon, 15 Jun 2020 14:08:28 +0200 > Subject: Re: [mkgmap-dev] Tiles missing > > Hi Joris, > > I didn't install the map in basecamp but if it can help, I will. > > On my device I've moved all maps in a separated directories to disable > them. The only one left was mine. > > To create the France map, I started from belgium-latest.osm.pbf downloaded > from geofabrik.de. Then I splitted it using splitter (r597) tool and then > generated the map with mkgmap (r4525). The mkgmap command line option was: > > java -Xmx8G -jar $MKGMAP_DIR/mkgmap.jar --gmapsupp \ > --family-id=$FAMILY_ID \ > --product-id=0 \ > --product-version=1 \ > --draw-priority=20 \ > --family-name="OSM $COUNTRY_ISO" \ > --series-name="OSM $COUNTRY_ISO" \ > --country-name="$COUNTRY" \ > --country-abbr="$COUNTRY_ISO" \ > --max-jobs=8 \ > --latin1 \ > --index \ > --split-name-index \ > --housenumbers \ > --reduce-point-density=4 \ > --reduce-point-density-polygon=8 \ > --min-size-polygon=8 \ > --polygon-size-limits="24:12, 18:10, 16:8, 14:4, 12:2, 11:0" \ > --route \ > --make-opposite-cycleways \ > --add-pois-to-areas \ > --process-destination \ > --process-exits \ > --order-by-decreasing-area \ > --keep-going \ > --style-file=$MKGMAP_DIR/resources/styles --style=default \ > --bounds=$BOUNDS_FILE \ > --precomp-sea=$SEA_FILE \ > -c template.args ../typ/2000.typ \ > --description="OSM custom routable(${COUNTRY_ISO}_$(date "+%d-%m-%Y"))" > > with template.args coming from the splitter step. > > Note that I've identified a (amongst several) missing tile and the name of > the tile was in the template.args. Moreover, the tile which doesn't display > on my device, is shown by GMapTool on the final IMG. > > Thanks for your help, > Pierre > > > > > > On Mon, Jun 15, 2020 at 1:39 PM Joris Bo <jorisbo(a)hotmail.com> wrote: > >> Hi Brico, >> >> >> >> Does your newly created map displays in basecamp correctly? >> >> If no: The start is to find out why tiles are skipped by mkgmap or >> splitter by investigating the error logging (This is the tip of Ticker) >> >> If yes: A start could be to disable all maps on your device by renaming >> the *.IMG extension to *._IMG except your own map. >> >> You can find the maps on both the device as the SSD in the map garmin >> >> >> >> If you created the maps the most straight forward way (without specifying >> family id and tile number start for example) you can easily create >> duplicate tile numbers which could conflict with other mapmakers. Default >> all tiles start with 6324xxx1 >> >> >> >> >> >> >> >> *Van:* mkgmap-dev <mkgmap-dev-bounces(a)lists.mkgmap.org.uk> *Namens *Pierre >> Brico >> *Verzonden:* zondag 14 juni 2020 18:16 >> *Aan:* Development list for mkgmap <mkgmap-dev(a)lists.mkgmap.org.uk> >> *Onderwerp:* Re: [mkgmap-dev] Tiles missing >> >> >> >> >> >> Yes, my GPSMAP 66s runs the latest firmware (4.20 see >> https://www8.garmin.com/support/download_details.jsp?id=14337) >> >> >> >> Note that the France OpenTopoMap on the same device is working properly. >> >> >> >> I can also try the map on my 64s if this can help to identify the >> problem... >> >> >> >> >> >> On Sun, Jun 14, 2020 at 3:46 PM Ralf Kleineisel <ralf(a)kleineisel.de> >> wrote: >> >> Hi, >> >> Am 13.06.20 um 11:41 schrieb Pierre Brico: >> >> > A few months ago, I bought a Garmin GPSMAP 66s (I've already other >> >> > Now I would like to generate a map for my next holiday in France but I >> > have issues with missing tiles. >> >> does your device run the latest firmware? I had weird display problems >> with older firmware on my 64s. >> >> >> >> _______________________________________________ >> mkgmap-dev mailing list >> mkgmap-dev(a)lists.mkgmap.org.uk >> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >> >> _______________________________________________ >> mkgmap-dev mailing list >> mkgmap-dev(a)lists.mkgmap.org.uk >> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > _______________________________________________ > mkgmap-dev mailing list > mkgmap-dev(a)lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

5 13

Documentation build processes - Question for Steve Ratcliffe
by Ticker Berkin 24 Jun '20

24 Jun '20

Hi Steve The process for converting files like {svn}/doc/typ-compiler.txt to mkgmap-rNNNN.zip:doc/typ-compiler.txt are failing. For a while the resultant typ-compiler.txt has been chopped off after 8193 bytes. tuning.txt is zero bytes. The web versions: http://www.mkgmap.org.uk/doc/typ-compiler etc are correct. Also, what are the tools used to build the .txt and html versions of these files. Best wishes Ticker

3 9

Using regex , subst, substring or other to translate value to propercase
by Joris Bo 23 Jun '20

23 Jun '20

Hi Does somebody ever managed to change a tag-value to propercase/titlecase? For example Change: amsterdam into Amsterdam ? Searching the string with subst function and regex mostly works fine. Replace that search with a hardcoded or known stringvalue works fine Split the value with substring in two parts 1(a) and 2(msterdam) works fine. But I cannot come up with a way to change the small ‘a’ into a large ‘A’ (besides adding 26 rules to my style 😊) Anybody any more ideas? Kind regards, Joris

2 3