- mkgmap-dev - The mkgmap lists

BuildDEMFile problem
by nwillink 22 Nov '17

22 Nov '17

@ Frank I think I've come across a problem with the DEM subfile not being read by Basecamp. I've come across this whilst creating a map of the south east coast of the UK - the same may apply to Calais When I split the UK it does not show the dem files of Dover area - I created a small map.osm which may point to the problem http://www.pinns.co.uk/errs/map.zip <http://www.pinns.co.uk/errs/map.zip> DEM files are created but ignored by Basecamp Any ideas? r Nick -- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html

1 0

Re: [mkgmap-dev] DEM format Questions
by Frank Stinner 19 Nov '17

19 Nov '17

Hi Gerd, at first the good news. In the meantime i have build maps for Czech Republik, Germany, Austria, Switzerland and Italy, ever with 6 zoomlevels. I don't found an error. Of course, this is no evidence for the algorithm. And yes, there are a few mysterious things. I'm sure, what ever the garmin programmers done, they have found a very good compression for this special case. They don't waste a bit. But perhaps they think also to confuse all the snoopy guys on the world. Perhaps they say: hey let us take a special case, if the compression is not worse. I have no idea for the 158. I belief, we can see this as parameter. Perhaps garmin have found with trial and error, that 158 give smallest DEM's for a lot of areas on earth. Then it is more a "statistical" reason. By the way, the worst thing in my opinion is the rule for "Längencodierung". It is rather a "descriptiv" solution. Perhaps behind this is a more "mathematical theory", but i don't found it. Frank

2 2

Re: [mkgmap-dev] BuildDEMFile
by Frank Stinner 16 Nov '17

16 Nov '17

Hi Andrzej, i have the prog a little bit changed. Just it should be run. I don't know, what's going on with only 1 subtile column and a width < 64. If this not worked, i change it, so that we have in this case 64 points. If you have -w 0.90 and --dlon=0.0266666666666664, than there are only 34 points. Frank

2 1

BuildDEMFile
by Frank Stinner 16 Nov '17

16 Nov '17

Hi, there is a new version (8.11.2017), https://github.com/FSofTlpz/Garmin-DEM-Build/blob/master/BuildDEMFile/bin/B…. This version should be assume less memory. Reading HGT's should be faster. It seems, --lastcolstd isn't more necessary (?). By the way, the programm runs also with linux mint 18.2 and mono. Main options: -d, --dem=arg name of DEM-file, (e.g. 70210001.DEM) --hgtpath=arg directory for HGT's (zipped or not) --tre=arg name of TRE-file (e.g. 70210001.TRE) -o, --dlon=arg distance between DEM-Point (multiple usage for more zoomlevels) --usedummydata=arg use 'without-value' (0x8000), if one or more HGT's not present --lastcolstd=arg last subtile column has ever a width of 64 (need a little bit more memory on disk) -O, --overwrite=arg overwrite existing destination files or not -f, --foot=arg DEM data in foot or meter Frank --- Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft. https://www.avast.com/antivirus

4 6

Re: [mkgmap-dev] DEM format Questions
by Frank Stinner 15 Nov '17

15 Nov '17

Hi Gerd, yes this is an error. Fortunately is the copy-constructor not in use. Frank

2 1

hgt2osm questions
by nwillink 13 Nov '17

13 Nov '17

@ Frank What a great tool for creating contour lines! 1) I'm having some success with your other great program,osm2hgt , however I fail to merge two or more .hgt files into a single osm . Am I doing something wrong? C:\Users\Owner\Desktop>E:\hgt2osm.exe --HgtPath=E:\Dem\All_UK_HGT_Data\ --Lat=49 --Lon=-3 --Outfile=e:\dev1.osm --Mergefile=e:\devonall2.osm C:\Users\Owner\Desktop>E:\hgt2osm.exe --HgtPath=E:\Dem\All_UK_HGT_Data\ --Lat=49 --Lon=-4 --Outfile=e:\dev2.osm --Mergefile=e:\devonall2.osm devonall2.osm doesn't seem to have merged both files. 2) I'm having to enter longitude data into --Lat and latitude into --Lon . Any reason why? 3) It hangs when there is no data , ie Hgt2Osm, 26.4.2017, FSofT 64 Bit-OS: ja Programmodus 64 Bit: ja MinorDistance: 20 MediumFactor: 5 MajorFactor: 5 HGT-Verzeichnis: E:\Dem\All_UK_HGT_Data\ Mergefile: e:\devonall2.osm OutputOverwrite: False Höhenkorrektur: -0.5 MinVerticePoints: 3 MinBoundingbox: 0.0005 Douglas-Peucker: 0.04 1. OSM-ID: -1 mit OSMBound: False mit OSMBounds: True mit OSMTimestamp: True mit OSMVersion: 1 mit OSMVisible: False max. Punktanzahl je Weg: 500 mit 'contour_ext'-Tag: True ==> Lese Ausgangsdaten 49° -4° ... Daten übernehmen ... Startzeit: 17:13:29 8 Threads übernehme 1201x1201 Werte für neue Matrix 1201x1201 ungültige Originalwerte: 0 (0.00%) berechne alle Strecken für Höhenlinien in 1440000 Rechtecken mit je 4 Dreiecken ... Laufzeit: 00:00:00 führe alle Strecken je Höhenebene eindeutig in einer Liste zusammen ... Laufzeit: 00:00:00 0 Höhenebenen von 2147483647 bis -2147483648 mit insgesamt 0 Strecken gebildet . .. -- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html

3 3

Re: [mkgmap-dev] DEM format Questions
by Frank Stinner 13 Nov '17

13 Nov '17

Hi Gerd, we have ever 2 problems: how to calculate the next value and how we have to encoding this value. #1: If we have not a plateau, then we have a "Standardwert". For the calculation of a "Standardwert" we have to 3 differend cases depend on the value hdiff(n, m-1) = h(n, m) - h(n-1, m) (horizontal difference, see at the end of "Datenberechnung"). max is highest possible value in this 64x64-subtile. #2: We have to decide, is it "Längencodierung", "Hybride Codierung" or if they are not possible, "Binärcodierung für große Zahlen". But we have no choice, we have to use that kind, that the algorithms say (see " Umschaltung der Codierart"). That do in TileEncoder.cs the class CodingType and the derived classes. I'm sorry, but TileEncoder.cs is not written for speed or good understanding. It is only for exploring DEM and, in Input2, for showing, what's going on. There is much place for optimizing. ;) Frank

2 1

Re: [mkgmap-dev] hgt2osm questions
by Frank Stinner 13 Nov '17

13 Nov '17

Hi, 1) It's a mistake. You can use lat/lon multiple. Only this tiles you can merge. But i think, that's useless. It's better to take the necessary results and merge this with osmosis (see https://github.com/FSofTlpz/Hgt2Osm2/blob/master/README.md) 2) Oops, a stupid error. Usual i don't use lat/lon. Using --HgtPath is easier for me. 3) Unfortunately i can't reproduce this effekt. You have probably do that (?): hgt2osm --HgtPath=E:\Dem\All_UK_HGT_Data\ --Mergefile=e:\devonall2.osm The prog take then all HGT's in the hgt-path, produce files like clN40W006.osm.gz and at last e:\devonall2.osm. I see "==> Lese Ausgangsdaten 49° -4° ...". Have you really a file N49W004.hgt.zip or S04E049.hgt.zip? I think, that's all water between france and GB or eastwards from africa. I have updated the prog. Frank

2 1

How to deal with tag aeroway=runway either made as polygon or as line
by Manfred Haiduk 12 Nov '17

12 Nov '17

Hi just now i stuck with the following rendering trouble. As you can see from the attached pictures, these two airports have identically tags for the runway, but the Wittmund runway is made out of a polygon and the Jever runway is made out of a line. If i put the rendering cmd into the line style file, Wittmund airport will be drawn with two runways and a gap in between. If i put the aeroway=runway item into the polygon style file, Wittmund will be drawn correctly, but Jever could not be drawn, as there is no polygon used for the runway.Using the aeroway=runway tag in both style files, will lead again Wittmund runway to be drawn as if there were two of them and no polygon underlying it. Is there any trick within the style file, to get a correct drawing with this inconsistency or is the only way to change, edit these airfield in the OSM database? -- Mit freundlichen Grüßen ##################################################### Manfred Haiduk, Zum Fischbach 9, 52393 Hürtgenwald e-mail mhaiduk(a)t-online.de #####################################################

3 3

Re: [mkgmap-dev] DEM format Questions
by Frank Stinner 10 Nov '17

10 Nov '17

Hi Gerd, which 0-Bit you mean? Let us take this example: 4,4,4,5,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7 8,8,5,5,5,5,5,8 The detailview from my prog "Input2" ( https://github.com/FSofTlpz/Garmin-DEM-Build/blob/master/Input2/bin/Input2.… ) show us: MaxHeigth=158, Codingtype=0, TileSize=64x64, BaseHeigthUnit=1, HeigthUnit=0, ActualMode=notdefined, ActualHeigth=0 Line 0 Idx=0, Plateau Length=0 TableIdx=0 Bits=0 [.] <> Idx=0, PlateauFollower ActualHeigth=4, Value=4 PlateauFollower0 [...11] Hybrid1 ddiff=0 Idx=1, ActualHeigth=4, Value=0 Standard [1.] Hybrid1 ... Idx=62, ActualHeigth=7, Value=0 Standard [1] Length0 Idx=63, ActualHeigth=7, Value=0 Standard [1] Length0 Line 1 Idx=0, Plateau Length=0 TableIdx=0 Bits=0 [.] <> Idx=0, PlateauFollower ActualHeigth=8, Value=4 PlateauFollower0 [.111] Hybrid2 ddiff=0 Idx=1, ActualHeigth=8, Value=0 Standard [1] Length0 Idx=2, ActualHeigth=5, Value=-3 Standard [......1] Length0 Idx=3, Plateau Length=4 TableIdx=3 Bits=1 [1111..] <111a> Idx=7, PlateauFollower ActualHeigth=8, Value=-1 PlateauFollower1 [.1.] Hybrid1 ddiff=2 Between the brackets [ and ] are the bits (. means 0). There is no special case. If a plateau have to begin, we have as first the plateau-length (see "Codierung der Plateaulänge"). There is ever a 0-Bit between the 2 parts of length-coding, also when plateau-length=0 (often on start of a line). As next we have the height-coding for the follower. Frank

2 1