November 2017 - mkgmap-dev - The mkgmap lists

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

DEM format Questions
by Gerd Petermann 10 Nov '17

10 Nov '17

Hi Frank, If I got that right your program always writes a 0-Bit to signal the beginning of a "plateau". While working on the decoder I wonder what this information is used for. My understanding is that both the reader and the writer know when a plateau starts, so there should be no need for this extra 0-Bit. On the other hand, the pdf says "Für Plateau-Nachfolger wird ein 0-Bit weniger als maximalen 0-Bitanzahl verwendet!" Maybe you created special cases because of this 1st 0? Gerd

2 1

Rendering Error at Region FR-Saint Maximin la Sainte Baume and around Gibraltar
by Manfred Haiduk 09 Nov '17

09 Nov '17

Hallo i'm not quite sure, if this error is related to mkgmap or the OSM-Database. Just fiddling around making maps for my garmin device. The last three times, when i compiled my europe map, i have to discover two errors. The region around Gibraltar will not show up the mediterranian sea but the underlying terrain will show up as "unknown terrain". This error is only about 80 km around Gibraltar with Gibraltar nearly in the center. The other error is in the vicinity of the area called by splitter FR-Saint Maximin la Sainte Baume. At this complete square the default terrain layer is not compiled as undefined area but as sea. Any idea, if these errors are due to mkgmap or osm database ? -- Mit freundlichen Grüßen ##################################################### Manfred Haiduk, Zum Fischbach 9, 52393 Hürtgenwald e-mail mhaiduk(a)t-online.de #####################################################

2 2

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

09 Nov '17

Sorry, this version is catching on negativ values the false HGT's. It is just rectified. Frank

2 1

a new DEM-File Option
by Frank.Stinner 06 Nov '17

06 Nov '17

Hi, i have find with a lot of "trial and error" a algorithm to create DEM-Files for a Height-Profil. You can find the description (in german) at https://github.com/FSofTlpz/Garmin-DEM-Build/blob/master/DEM-Daten.pdf With this data we can for example draw a track in mapsource or basemap and we at once the Height-Profil of our track. At second, the map looks like better. I have create a experimental program called BuildDEMFile :) to build this files. Experimental means, the encoder is for exploring the algorithm but not for speed. You can find the programit at https://github.com/FSofTlpz/Garmin-DEM-Build. It is possible, that there minor bugs, but i have it successfull testet for 2 different germany-maps. I have a wish: Can you in mkgmap insert a new option, for example --dem with path to DEM-files, and include these files in the join-process for the IMG-files? So far only joined the LBL-, NET-, NOD-, RGN- and TRE-File. Also should be set the dem-flag in TDB-File. If so, i can build the DEM-Files with area-size from the splitter-file areas.list. I hope thats the same like in the TRE-Files? That would be a little bit easier then my fiddly way: split the ready IMG-files, build the DEM-files and then join the files to new IMG-files. And at last i must change the dem-flag in the TDB-File. with best regards Frank --- Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft. https://www.avast.com/antivirus

11 55

line draw order
by demon.box 02 Nov '17

02 Nov '17

Hi, excuse me, but I don't understand.... With these style in lines: waterway=river [0x1000B resolution 24] highway=tertiary [0x3 road_class=4 road_speed=7 resolution 24] I have this result: <http://gis.19327.n8.nabble.com/file/t339261/1.jpg> where the road cross the river but with this style in lines: waterway=river [0x1000B resolution 24] highway=tertiary [0x5 road_class=4 road_speed=7 resolution 24] (I have only changed the tertiary type from 0x3 to 0x5) I have this result: <http://gis.19327.n8.nabble.com/file/t339261/2.jpg> where the river cross the road... I use these options: add-pois-to-lines preserve-element-order remove-short-arcs latin1 lower-case check-styles route index name-tag-list=name:it,name adjust-turn-headings merge-lines pois-to-areas-placement="building=entrance" split-name-index housenumbers why is there this difference only changing the road type from 0x3 to 0x5? how can I make the 0x5 (road) type cross the 0x1000B (river)? thanks. --enrico -- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html

3 2