April 2020 - mkgmap-dev - The mkgmap lists

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

default style points enhancements
by Ticker Berkin 09 Jun '20

09 Jun '20

Hi Gerd and followers of the default style Here are some enhancements to default style "points" - patch attached. I've been building up a list of changes to the default style for a while, and, with the current discussion about multiple POI for a single OSM object and the benefit of benches (I've just added this), it seemed like a good time to put forward these changes. Some of these derive from: http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2019q4/030097.html Some from other comments in this forum and the rest are from when I've noticed something wrong or that could be improved. Summary of changes: - for amenity={atm/bar/cafe} allow additional POI from other tags, eg shop=bakery or any others: leisure/tourism/sport/...=... - create POI 0x6605 for bench (Geographic>Land>Bench) - don't create POI for private parking - create parking POI for parking_entrance - if parking unnamed, use access tag if exists, giving names like "Customer parking", "Permissive parking"... - explicit shelter_type=basic_hut rather that trying to exclude bus shelters etc for Find>Lodgings - marina code from 0x4300 to 0x2f09; searchable as "Others" - POI for nature_reserve, even if not named - don't create POI for pitch if no name or sport - don't create POI for private swimming pools - don't create POI for unnamed cliff - add POI 0x6503 for named bay (Geographic>Water>Bay) - for platforms, just 1 POI when --add-pois-to-lines - name unnamed shops as category, regardless of category being matched - add, commented out, extra shop categories supported by some devices - add POI for shop=outdoor - for {camp/caravan}_site have BOTH 0x2b03 AND 0x2b05; 03 not shown on modern devices, 05 not shown on old devices - have both Food & Lodging POI for same point if appropriate - landuse=basin code from 0x650f (Geographic>Water>Reservoir) to 0x6603 (Geographic>Land>Basin) - water=reservoir as well as landuse=reservoir - add POI 0x650d for named water=lake/pond (Geograhic>Water>Lake) I'm happy to explain any of these change in more detail and, if anyone considers a particular change incorrect, provide a revised patch. Ticker

3 6

Re: [mkgmap-dev] License File <mapid>000_license.txt
by Mike Baggaley 28 May '20

28 May '20

Answering my own question - I have realised that this is created by the --nsis option, which I had mistakenly got in my config file, and is used by the NSIS installer rather than the maps themselves. However, it seems illogical to me that this should not use the contents of --license-file. Cheers, Mike -----Original Message----- From: Mike Baggaley [mailto:mike@tvage.co.uk] Sent: 16 April 2020 19:34 To: 'Development list for mkgmap' <mkgmap-dev(a)lists.mkgmap.org.uk> Subject: License File <mapid>000_license.txt Hi all, I notice that mkgmap creates a file named <mapid>000_license.txt that contains the following text: Map data (c) OpenStreetMap and its contributors http://www.openstreetmap.org/copyright This map data is made available under the Open Database License: http://opendatacommons.org/licenses/odbl/1.0/. Any rights in individual contents of the database are licensed under the Database Contents License: http://opendatacommons.org/licenses/dbcl/1.0/ Map created with mkgmap-r4473M This does not seem to be displayable in either Basecamp or Mapsource and does not contain the txt from my --license-file option. Can anyone explain what this file is for and whether there is a registry setting to get Basecamp/Mapsource to display it? Also whether there is a reason it does not contain the text from the --license-file option? Cheers, Mike

3 11

nearby POIs
by Mike Baggaley 04 May '20

04 May '20

Hi Gerd, please find attached a patch for handling the removal of duplicate POIs that are near to each other but not coincident. The existing code handles the removal of coincident duplicates, but leaves other duplicates in place. It is very common in OSM for buildings to be tagged as amenities with a single node also being tagged as the same amenity. If using --add-pois-to-areas, this can lead to a lot of duplication. The patch provides a new command line option with the following syntax: --nearby-poi-rules=type[/all|/named|/unnamed]:max-distance[:delete-poi|delet e-name|merge-at-mid-point][,...] This defines a set of rules to follow when a POI is near to another of the same type. Each rule consists of three parts separated by colons. The first two parts must be provided; the last part can be defaulted. The first part of the rule is the Garmin POI type code with an optional suffix; it determines when the rule is triggered. The type code may be specified in decimal or hexadecimal (e.g. 0x2c0b). A rule is triggered when processing a POI if the type code of the POI matches the rule type, providing there is also a match in the POI name and the first part suffix. If the suffix is '/all' (the default) then the match is only made on the type. If the suffix is '/named' then the rule is only triggered if the POI has a name. If the suffix is '/unnamed' then the rule is only triggered if the POI has no name. A wildcard of an asterisk character may be used to match any type code. The wildcard may also be combined with a suffix to allow separate processing of named and unnamed POIs. The second part of the rule is the distance in metres which an already processed POI must be within for it to be considered to be nearby and hence trigger the action part of the rule. The third part of the rule is the action part and provides three options: ::delete-poi - the POIS are considered to be duplicates and the duplicate is deleted. This is the default. ::delete-name - the POIS are not duplicates, but only a single name needs to be displayed. ::merge-at-mid-point - the POIS are considered to be duplicates but the location of the existing point is moved to a point midway between the two points. Wildcard rules are only applied if no other rule is applicable. For example: : --nearby-poi-rules=*/named:50,*/unnamed:25,0x2f1f/named:50:delete-name,0x2f1 f:3,0x641d:400:merge-at-mid-point This has the following effect: : If no other rule applies, a POI with the same name and type and within 50m of one already processed will be deleted If no other rule applies, a POI having no name and of the same type and within 25m of one already processed will be deleted A POI of type 0x2f1f that is within 50m of another POI with the same name and type will have its name deleted A POI of type 0x2f1f that is within 3m of another POI with the same type will be deleted A POI of type 0x641d that is within 400m of another POI with the same type will be deleted and the existing point moved Note: a POI that matches another in type, name and exact location is always considered a duplicate and deleted. Regards, Mike

5 37

Commit r4485: Implement and document new options --nearby-poi-rules and --nearby-poi-rules-config
by svn commit 30 Apr '20

30 Apr '20

Version mkgmap-r4485 was committed by gerd on Thu, 30 Apr 2020 Implement and document new options --nearby-poi-rules and --nearby-poi-rules-config Patch nearbyPOI8.patch by Mike Baggaley http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4485

1 0

Commit r4484: improve/correct example roadNameConfig.txt (patches by Ticker Berkin and Mike Baggaley)
by svn commit 27 Apr '20

27 Apr '20

Version mkgmap-r4484 was committed by gerd on Mon, 27 Apr 2020 improve/correct example roadNameConfig.txt (patches by Ticker Berkin and Mike Baggaley) http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4484

1 0

[Fwd: Re: Suggestions for roadNameConfig.txt]
by Ticker Berkin 27 Apr '20

27 Apr '20

Hi Gerd Could you consider this change to roadNameConfig.txt for GBR I've attached an updated version based current trunk.o1 Thank you Ticker -------- Forwarded Message -------- From: Ticker Berkin <rwb-mkgmap(a)jagit.co.uk> Reply-to: Development list for mkgmap <mkgmap-dev(a)lists.mkgmap.org.uk> To: Development list for mkgmap <mkgmap-dev(a)lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] Suggestions for roadNameConfig.txt Date: Thu, 23 Jan 2020 16:56:17 +0000 Hi Gerd I've just been going through some old mails/patches. I think the updated contents of roadNameConfig.txt is correct and better than the previous version. The fact that it doesn't work consistently across devices and, on some, is misleading shouldn't stop the file being available as an example in the distribution. The user has the choice about how to use it and it contains some comments and a link relating to these problems. I've attached an updated patch with UTF-8 encoding markers, a different section for UK road names and improved some comments. This file has always been read by mkgmap as UTF-8. The function of the markers is to make editors aware of this; it contains characters outside the 7-bit ascii range. Ticker On Mon, 2019-12-16 at 11:30 +0000, Gerd Petermann wrote: > Hi Ticker, > > reg. search: You are probably right, address search works very > different on the Garmin devices. On the Oregon, I have several > dialogs, first to chose country, next to chose city or "all", next to > type house number, last one asking for road name. In this dialog > there is no autocompletion, I just have to type characters. Sometimes > the device switches automatically to a result list while I am typing, > sometimes it doesn't. When I press OK I get a list of matching roads. > So, for the Oregon it works fine. Maybe it doesn't for those devices > with auto-completion. Cannot test this right now. I tried it once > with a Nüvi and it seemed to work well, but I don't own one. > > Reg. combination of --road-name-config and --split-name-index: Yes, > this gives confusing results. Not sure if it worked better in the > past. > I tried with Essex extract: > java -jar d:\mkgmap\dist\mkgmap.jar --bounds=f:\osm\bounds.zip - > -gmapi --net --index --road-name > -config=d:\mkgmap\resources\roadNameConfig.txt --gmapsupp --split > -name-index f:\dwnload\temp\essex-latest.osm.pbf > > > According to Mapsource a search for "Mace" without giving a city name > should list "John Mace Road", "Mace Avenue", "Mace Court", and "Mace > Walk", maybe in a different order. > Without your patch I get a list showing "Mace Road", "Mace Avenue", > and "Mace Walk", so "Mace Court" is missing and when I select "Mace > Road" the device shows the "John Mace Road". > With your patch this gets worse: The list shows only "Mace Road", > when I select that entry I get a new list containing > ",Thurrock","Braintree,Essex","Chelmsford,Essex", and "Colchester, > Essex". Each of them points to just one of the expected roads. > > Results look much better when I specify a city name. > Result also looks very different without the --split-name-option. > I have to do more tests, I think it worked better in the past. Maybe > sorting is broken. > > Gerd

4 12

Extending metadata mkgmap default logging output
by Joris Bo 25 Apr '20

25 Apr '20

Hello, Is there a way to get the mkgmap version number in the logfile? I know it is possible to use the -version option but this means an extra execution of mkgmap. There is already a default output like this: Time started: Thu Apr 23 07:56:43 CEST 2020 Found one style in ..\..\Dropbox\Garmin\Build\Style - Jbm finished check-styles Number of MapFailedExceptions: 0 Number of ExitExceptions: 0 Time finished: Thu Apr 23 07:57:17 CEST 2020 Total time taken: 33 seconds Could the mkgmap version number be part of this metadata? Kind regards, Joris

3 3

"Small" SRTM1 files and DEM maps
by Carlos Dávila 21 Apr '20

21 Apr '20

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?

5 11

Re: [mkgmap-dev] "Small" SRTM1 files and DEM maps
by Carlos Dávila 19 Apr '20

19 Apr '20

I also searched for info about this format before posting to the list, but could not find anything either:-( El 17/4/20 a las 6:19, Gerd Petermann escribió: > Hi all, > > I could not find any information about this special format. Would be great if someone could point me to a detailed documentation. > > Gerd > > ________________________________________ > Von: Gerd Petermann <gpetermann_muenchen(a)hotmail.com> > Gesendet: Donnerstag, 16. April 2020 18:06 > An: Carlos Dávila > Betreff: AW: [mkgmap-dev] "Small" SRTM1 files and DEM maps > > Hi Carlos, > > the hgt files are very simple. They contain an array of n * n 16-bit values, nothing else. The 16-bit value gives the elevation, and the file name gives the position of the southwest corner, see https://stackoverflow.com/questions/357415/how-to-read-nasa-hgt-binary-files > Maybe the 12.4 MB files use 8-bit values for the elevation, but 12.970.802 / 3601 gives 3602, so there is probably an extra byte giving a delta value. > Coud not find a desription of this format so far. I'll try to find out more. > > Gerd > > ________________________________________ > Von: Carlos Dávila <carlos(a)alternativaslibres.org> > Gesendet: Donnerstag, 16. April 2020 17:39 > An: Gerd Petermann > 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 >>>> _______________________________________________ >> _______________________________________________ >> 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

2 2