- mkgmap-dev - The mkgmap lists

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

Commit r4483: fix documentation for --licence-file reg. underscores
by svn commit 19 Apr '20

19 Apr '20

Version mkgmap-r4483 was committed by gerd on Sun, 19 Apr 2020 fix documentation for --licence-file reg. underscores $LONG_DATE$ -> $LONGDATE$, $SHORT_DATE$ -> $SHORTDATE$ http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4483

1 0

License File <mapid>000_license.txt
by Mike Baggaley 16 Apr '20

16 Apr '20

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

1 0

POI barrier/access restriction
by Ticker Berkin 15 Apr '20

15 Apr '20

Hi Gerd and others interested in routing issues default style "points" has code that, when option --link-pois-to-ways is in effect, sets highway access and speed restrictions that mkgmap then imposes on the highway that the point is on. These rules had various errors: - didn't expand the access mode hierarchy, see https://wiki.openstreetmap.org/wiki/Key:access - tested the wrong tag for mkgmap:bus and mkgmap:delivery - if the "access" tag was set, apply this to all modes before processing allowances and restrictions imposed by the barrier; but these actions would have no effect because the the specified mode tags are now all set - assumed that a gate stops motor_vehicle access - didn't handle other common forms of gate - allowed bicycle through kissing_gate and stile This patch fixes these problems and also adds a speed restriction for all barriers. The general principle is that barrier rules add specific "no" restrictions that the barrier prevents, but must not add "yes". The "access" tag is a default for all modes not implicitly or explicit handled; there could be, say, osm tags [barrier=stile, access=destination] and this should not imply there is unrestricted foot access. Ticker

3 10

Commit r4482: improve evaluation of barrier=* nodes (barrierAccess.patch by Ticker Berkin)
by svn commit 15 Apr '20

15 Apr '20

Version mkgmap-r4482 was committed by gerd on Wed, 15 Apr 2020 improve evaluation of barrier=* nodes (barrierAccess.patch by Ticker Berkin) Default style "points" has code that, when option --link-pois-to-ways is in effect, sets highway access and speed restrictions that mkgmap then imposes on the highway that the point is on. These rules had various errors: - didn't expand the access mode hierarchy, see https://wiki.openstreetmap.org/wiki/Key:access - tested the wrong tag for mkgmap:bus and mkgmap:delivery - if the "access" tag was set, apply this to all modes before processing allowances and restrictions imposed by the barrier; but these actions would have no effect because the the specified mode tags are now all set - assumed that a gate stops motor_vehicle access - didn't handle other common forms of gate - allowed bicycle through kissing_gate and stile This patch fixes these problems and also adds a speed restriction for all barriers. The general principle is that barrier rules add specific "no" restrictions that the barrier prevents, but must not add "yes". The "access" tag is a default for all modes not implicitly or explicit handled; there could be, say, osm tags [barrier=stile, access=destination] and this should not imply there is unrestricted foot access. http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4482

1 0

Commit r4481: Improve documentation of options (Patch by Ticker Berkin)
by svn commit 14 Apr '20

14 Apr '20

Version mkgmap-r4481 was committed by gerd on Tue, 14 Apr 2020 Improve documentation of options (Patch by Ticker Berkin) - layout and spacing - gmapi and family-name - generate-sea options http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4481

1 0

options.txt improvements
by Ticker Berkin 14 Apr '20

14 Apr '20

Hi Gerd Some improvements to options.txt: - layout and spacing - gmapi and family-name - generate-sea options Ticker

1 0

Commit r4480: Ignore tags with empty value when reading OSM files.
by svn commit 13 Apr '20

13 Apr '20

Version mkgmap-r4480 was committed by gerd on Mon, 13 Apr 2020 Ignore tags with empty value when reading OSM files. http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4480

1 0

handling of a key without a value
by J J 11 Apr '20

11 Apr '20

https://www.openstreetmap.org/node/7278416985 That node seems to crash my style while trying to execute the following command: ele=* {echo 'ele=${ele}'; set ele_m='${ele|conv:"ft=>m"}'; echo 'ele_m=${ele}'; } The echo command produces "ele=" in the transcript, afterwards "java.lang.StringIndexOutOfBoundsException: String index out of range: -1" etc. The node contains any empty values. "ele" is the only of them my style uses. Observed in: mkgmap-r4478

2 2

splitter and options --description / --geonames-file
by Gerd Petermann 10 Apr '20

10 Apr '20

Hi all, this is a follow up of http://gis.19327.n8.nabble.com/documentation-improvement-tp5962609p5962747.… Since I don't use these options for my maps I am unsure what is best. The --geonames-file option tries to find a city within the calculated tile. If none is found it either writes the value given with --description or just a comment. I think it would be best to always write the nearest city. Gerd

4 9