March 2023 - mkgmap-dev - The mkgmap lists

Fix and augment sort definitions
by Gerd Petermann 12 Oct '23

12 Oct '23

Hi Ticker, see https://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3948 https://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3949 the sortResource.patch reverts these changes. In Mapsource the results are a bit better with your patch. I'll try again with my Oregon later. Gerd

3 15

Problems with contours
by helter skelter 10 Apr '23

10 Apr '23

Hello guys I don't know if this is the right place to ask: please forgive me if not and delete my request. I have a problem with contours, generated from DEM HGT files, downloaded both from Nasa and Viewfinder, and tried with different Douglas-Peucker values. I get empty spaces in some areas of the map, close to the state/region border, and squares with no DEM data, as you can see in this picture (this is the north part of Trentino Alto Adige, north of Italy): [cid:7f488b98-a01f-4538-bd2a-fe8ca3b4d4fa] I use HGT2OSM and OSMCONVERT to process all HGTs and obtain a single OSM file, the I split it with the Splitter. Then I merge everything in a single IMG file with MKGMAP. Do you know what could be the reason of this problem and how to solve ? Thank you in advance for all your help Regards, Diego

5 4

SSL certificate expired
by Sebastiaan Couwenberg 29 Mar '23

29 Mar '23

The Let's Encrypt SSL certificate expired today: Certificate chain 0 s:CN = lists.mkgmap.org.uk i:C = US, O = Let's Encrypt, CN = R3 a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256 v:NotBefore: Dec 29 03:31:18 2022 GMT; NotAfter: Mar 29 03:31:17 2023 GMT If it was renewed nginx may need to be restarted to use the update cert. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1

1 0

Strange behavior of contour lines for different resolutions
by Daniel Vogelbacher 26 Mar '23

26 Mar '23

Hi all, I want to generate an overlay map with contour lines. The following style works as expected: contour=elevation & contour_ext=elevation_minor & (ele > 0 | ele < 0) { name '${ele|conv:m=>ft}'; } [0x20 resolution 24] contour=elevation & contour_ext=elevation_medium & (ele > 0 | ele < 0) { name '${ele|conv:m=>ft}'; } [0x21 resolution 20] contour=elevation & contour_ext=elevation_major & (ele > 0 | ele < 0) { name '${ele|conv:m=>ft}'; } [0x22 resolution 17] Major lines are visible up from resolution 17, medium from resolution 20 and minor on highest resolution (24). If I change the style to: contour=elevation & contour_ext=elevation_minor & (ele > 0 | ele < 0) { name '${ele|conv:m=>ft}'; } [0x20 resolution 24] contour=elevation & contour_ext=elevation_medium & (ele > 0 | ele < 0) { name '${ele|conv:m=>ft}'; } [0x21 resolution 21] contour=elevation & contour_ext=elevation_major & (ele > 0 | ele < 0) { name '${ele|conv:m=>ft}'; } [0x22 resolution 17] Major lines are visible up from resolution 17, but together with medium lines, minor lines are visible starting from resolution 21, too. Same effect for choosing resolution 22 or 23 for medium lines. Medium and minor lines are visible always together for medium-resolutions >= 21. As the effect is the same on QMapShack and GPSMap 66s, I assume the problem is in the map. Any ideas what can cause the problem? What I finally want to build is: contour=elevation & contour_ext=elevation_major & (ele > 0 | ele < 0) { name '${ele|conv:m=>ft}'; } [0x20 resolution 18-21 continue] contour=elevation & contour_ext=elevation_minor & (ele > 0 | ele < 0) { name '${ele|conv:m=>ft}'; } [0x20 resolution 24] contour=elevation & contour_ext=elevation_medium & (ele > 0 | ele < 0) { name '${ele|conv:m=>ft}'; } [0x21 resolution 23] contour=elevation & contour_ext=elevation_major & (ele > 0 | ele < 0) { name '${ele|conv:m=>ft}'; } [0x22 resolution 22] I've reduced this to the styles above to isolate the problem. mkgmap r4907 here. Tried r4900 as well. java -jar fzk-mde-garmin/Freizeitkarte-Entwicklung/tools/mkgmap/mkgmap.jar --copyright-message="Sonny DEM" --series-name="DEM Europe 10m" --description="DEM for Europe v17 10m 250m/50m" --family-name="DEM Europe" --country-name=Europe --country-abbr=EU --area-name=EU --product-version="202303" --reduce-point-density=0.2 --reduce-point-density-polygon=0.2 --min-size-polygon=1 --name-tag-list=name,place_name,loc_name --order-by-decreasing-area --style-file=contourmap/style/ --latin1 --transparent --no-poi-address --gmapsupp -c contourmap/mkgmap.europe.cfg -c /workbench/main/osm/splitter/contours_v17_10m_250_50/template.args contourmap/typ/contours.txt -- Best regards / Mit freundlichen Grüßen Daniel Vogelbacher -- Best regards / Mit freundlichen Grüßen Daniel Vogelbacher

2 2

Re: [mkgmap-dev] RGN Section 6 and part of TRE Section 7
by thomas＠ankarsvik.nu 24 Mar '23

24 Mar '23

Hi Ticker, To much to do with to little time to spend. I can't find anything that gives a hint of the extra byte in some TRE S7 rows. TRE-S7 are offset columns UInt32 | UInt32 |UInt32 | Byte | UInt32 columns ------------------------------------------------------- Polygon | Line | Point | Flag byte | Col1 | Col2 | Coln The smallest map you can produce is one area, like a lake, or other land. That gives Polygon- and Col1- column mandatory. Line, Points, Flag byte are all optional with respect to small maps. In well known sources like GPXSee, RGNDisplay and similar, all of them skip the bytes (of my interest). We know how to skip the extra bytes. The amount of extra columns follow map-size and complexity. Smallest map you can produce have 9 bytes per row. (What I have seen.) Polygon | Flag Byte | Col1 If we focus on Col1 .. Coln They are incremental by column. Example with 3 rows and 3 columns: Last row contain "Section sizes", 0x0048 is the size of RGN Section 6. 0x0000 | 0x0002 | 0x0015 0x0001 | 0x0008 | 0x0018 0x0001 | 0x0013 | 0x0032 0x0001 | 0x0013 | 0x0048 Sorry for any mis-postings done. BR. /Thomas

1 0

RGN Section 6 and part of TRE Section 7
by thomas＠ankarsvik.nu 16 Mar '23

16 Mar '23

Hi, Sorry if this is slightly of topic. This is a typical dump from a file without Huffman encoding. (RGN Section 5) TRE - Section 7 dump 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C -------------------------------------------------------------------------------------- Sec 2 | Sec 3 | Sec 4 | |Columns related to RGN Section 6 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 06 00 00 00 13 00 00 00 15 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 06 00 00 00 13 00 00 00 15 00 00 00 0B 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 06 00 00 00 13 00 00 00 15 00 00 00 17 00 00 00 00 00 00 00 06 00 00 00 01 00 00 00 00 06 00 00 00 13 00 00 00 15 00 00 00 24 00 00 00 12 00 00 00 0C 00 00 00 01 00 00 00 00 06 00 00 00 13 00 00 00 15 00 00 00 32 00 00 00 26 00 00 00 12 00 00 00 01 00 00 00 00 06 00 00 00 13 00 00 00 15 00 00 00 41 00 00 00 3D 00 00 00 18 00 00 00 00 06 00 00 00 13 00 00 00 15 00 00 00 1B 00 00 00 All rows except the last row is related to it's sublevel, Row 2 to sublevel 2 and so on. Explanation to last row 41 00 00 00 = RGN Section 2 Length 3D 00 00 00 = RGN Section 3 Length 18 00 00 00 = RGN Section 4 Length 01 = Flag (Not allways first sublevel per zoom-level) 06 00 00 00 = End of first part RGN Section 6 13 00 00 00 = End of second part in RGN Section 6 15 00 00 00 = End of third part in RGN Section 6 1B 00 00 00 = Total Length of RGN Section 6 RGN Section 6 dump 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F ----------------------------------------------- 0B 11 72 2C E5 36 19 11 04 4C 91 D7 FC 4B 11 BE CC 8F 1E E0 00 0B 11 72 2C E5 36 0B 11 72 2C E5 36 : 0B >> 1 gives following byte length of 5 19 11 04 4C 91 D7 FC 4B 11 BE CC 8F 1E : 19 >> 1 gives byte length of 12 decimal E0 00 : Seen E0 00 in other files 0B 11 72 2C E5 36 : 0B >> 1 gives following byte length of 5 Shifting the first byte to give following byte length seems to be valid if the value is odd. This is also valid within a byte array (amount of bytes in a sublevel) stated in TRE Section 7. 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F ----------------------------------------------- 15 11 70 7C 76 6F ED 1A 3E 2F 34 15 11 E0 AF F7 12 A7 CB CD 17 34 0D 11 8C 5A F9 2F 01 0D 11 E0 CF 70 D9 3A 0F 12 68 7C CC E6 F0 00 0D 12 E0 1E 80 79 1F 11 11 D4 0B 3E 19 00 17 0C 0D 01 78 B2 41 DB 11 0D 11 F4 D0 F3 D8 01 0D 11 24 7F 30 D7 15 11 70 7C 76 6F ED 1A 3E 2F 34 15 11 E0 AF F7 12 A7 CB CD 17 34 0D 11 8C 5A F9 2F 01 0D 11 E0 CF 70 D9 3A 0F 12 68 7C CC E6 F0 00 0D 12 E0 1E 80 79 1F 11 11 D4 0B 3E 19 00 17 0C 0D 01 78 B2 41 DB 11 0D 11 F4 D0 F3 D8 01 In a Huffman encoded file looks RGN Section 6 much more "random". 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F ----------------------------------------------- F9 9F 7F F8 3E 80 98 7D FC 09 45 F0 7C E6 E4 00 83 FF 7C 0A C8 E5 1F 40 40 FF 41 E4 80 CF FF C6 FF 7E C0 C9 40 F4 21 F2 FE 02 FF 33 F8 20 40 FF FC FF E1 21 1F 7E 06 FF FD 00 FC FF A1 8F 29 FB According to this file TRE Section 7 it should be splitted as F9 9F 7F F8 3E 80 98 7D FC 09 45 F0 7C E6 E4 00 The question is: Do anyone know what it might be in RGN Section 6. Even a bit more than what I found so far is of interest. Any hint in this topic is much appreciated. Best Regards /Thomas

2 1

RGN Section 6 and part of TRE Section 7
by thomas＠ankarsvik.nu 15 Mar '23

15 Mar '23

Hi, Sorry if this is slightly of topic. This is a typical dump from a file without Huffman encoding. (RGN Section 5) TRE - Section 7 dump 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C -------------------------------------------------------------------------------------- Sec 2 | Sec 3 | Sec 4 | |Columns related to RGN Section 6 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 06 00 00 00 13 00 00 00 15 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 06 00 00 00 13 00 00 00 15 00 00 00 0B 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 06 00 00 00 13 00 00 00 15 00 00 00 17 00 00 00 00 00 00 00 06 00 00 00 01 00 00 00 00 06 00 00 00 13 00 00 00 15 00 00 00 24 00 00 00 12 00 00 00 0C 00 00 00 01 00 00 00 00 06 00 00 00 13 00 00 00 15 00 00 00 32 00 00 00 26 00 00 00 12 00 00 00 01 00 00 00 00 06 00 00 00 13 00 00 00 15 00 00 00 41 00 00 00 3D 00 00 00 18 00 00 00 00 06 00 00 00 13 00 00 00 15 00 00 00 1B 00 00 00 All rows except the last row is related to it's sublevel, Row 2 to sublevel 2 and so on. Explanation to last row 41 00 00 00 = RGN Section 2 Length 3D 00 00 00 = RGN Section 3 Length 18 00 00 00 = RGN Section 4 Length 01 = Flag (Not allways first sublevel per zoom-level) 06 00 00 00 = End of first part RGN Section 6 13 00 00 00 = End of second part in RGN Section 6 15 00 00 00 = End of third part in RGN Section 6 1B 00 00 00 = Total Length of RGN Section 6 RGN Section 6 dump 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F ----------------------------------------------- 0B 11 72 2C E5 36 19 11 04 4C 91 D7 FC 4B 11 BE CC 8F 1E E0 00 0B 11 72 2C E5 36 0B 11 72 2C E5 36 : 0B >> 1 gives following byte length of 5 19 11 04 4C 91 D7 FC 4B 11 BE CC 8F 1E : 19 >> 1 gives byte length of 12 decimal E0 00 : Seen E0 00 in other files 0B 11 72 2C E5 36 : 0B >> 1 gives following byte length of 5 Shifting the first byte to give following byte length seems to be valid if the value is odd. This is also valid within a byte array (amount of bytes in a sublevel) stated in TRE Section 7. 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F ----------------------------------------------- 15 11 70 7C 76 6F ED 1A 3E 2F 34 15 11 E0 AF F7 12 A7 CB CD 17 34 0D 11 8C 5A F9 2F 01 0D 11 E0 CF 70 D9 3A 0F 12 68 7C CC E6 F0 00 0D 12 E0 1E 80 79 1F 11 11 D4 0B 3E 19 00 17 0C 0D 01 78 B2 41 DB 11 0D 11 F4 D0 F3 D8 01 0D 11 24 7F 30 D7 15 11 70 7C 76 6F ED 1A 3E 2F 34 15 11 E0 AF F7 12 A7 CB CD 17 34 0D 11 8C 5A F9 2F 01 0D 11 E0 CF 70 D9 3A 0F 12 68 7C CC E6 F0 00 0D 12 E0 1E 80 79 1F 11 11 D4 0B 3E 19 00 17 0C 0D 01 78 B2 41 DB 11 0D 11 F4 D0 F3 D8 01 In a Huffman encoded file looks RGN Section 6 much more "random". 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F ----------------------------------------------- F9 9F 7F F8 3E 80 98 7D FC 09 45 F0 7C E6 E4 00 83 FF 7C 0A C8 E5 1F 40 40 FF 41 E4 80 CF FF C6 FF 7E C0 C9 40 F4 21 F2 FE 02 FF 33 F8 20 40 FF FC FF E1 21 1F 7E 06 FF FD 00 FC FF A1 8F 29 FB According to this file TRE Section 7 it should be splitted as F9 9F 7F F8 3E 80 98 7D FC 09 45 F0 7C E6 E4 00 The question is: Do anyone know what it might be in RGN Section 6. Even a bit more than what I found so far is of interest. Any hint in this topic is much appreciated. Best Regards /Thomas

1 0

Problem with lakes and boundary lines
by helter skelter 14 Mar '23

14 Mar '23

Hello guys I have this problem when trying to render the map of separate regions of Italy, instead of the whole country. The problem is when there is a lake across the boundary line (it happens often in Italy). If I process the whole country, the lakes are rendered correctly, like in this picture: [cid:b8ce3c0e-7457-4e1b-9644-5d286af31541] (This is Lago Maggiore, between Piemonte and Lombardia regions, north of Italy) If I render each region separately, the lake is not rendered correctly. For example, rendering Lombardia I get this (picture from Basecamp) : [cid:40bae83a-938b-4afd-bda3-88803461f55d] The left part is not rendered because it’s another region (Piemonte) and this is ok. But also the lake is rendered completely wrong: only the south part has water (near Arona city) and in the north area the water is not rendered. If I create the map of Piemonte, I have the same problem but with different rendering errors. I see no water on the north and water covering a part of the land in center-right: [cid:2dd1d2da-af03-485f-ab6b-e7be0c7fcf28] Data of regions are downloaded from: http://download.openstreetmap.fr/extracts/europe/italy/ This is my SPLITTER configuration: Splitter version 653 compiled 2022-12-27T06:20:39+0000 boundary-tags=use-exclude-list cache= description= geonames-file= handle-element-version=remove ignore-osm-bounds=false keep-complete=true mapid=13224200 max-areas=2048 max-nodes=1600000 max-threads=16 (auto) mixed=false no-trim=false num-tiles= output=o5m output-dir=C:\OSM\splitter\PIEMONTE overlap=auto polygon-desc-file= polygon-file=C:\OSM\areas_poly\regioni\PIEMONTE.poly precomp-sea= problem-file= problem-report= resolution=13 route-rel-values= search-limit=200000 split-file= status-freq=120 stop-after=dist wanted-admin-level=5 write-kml= Elapsed time: 0s Memory: Current 248MB (4MB used, 244MB free) Max 16384MB Time started: Mon Mar 13 10:18:10 CET 2023 Map is being split for resolution 13: - area boundaries are aligned to 0x800 map units (0.0439453125 degrees) - areas are multiples of 0x800 map units wide and high These are some errors I see in Splitter log: Warning: Incomplete multipolygon relation 11758 (Lago Maggiore): using bbox of unclosed polygon to calc tiles, ways: [225950136, 123006579, 1073823032, 1073823028, 190504960, 87660763, 139898093, 87660754, 87660747, 255065025, 255065026, 255065027, 202250553, 202250554, 202252112, 256006208, 256006217, 256006211, 256006196, 202273125, 87660744, 87660769, 265419850, 265419849, 196817044, 202274997, 202274999, 202275000, 202274990, 202274996, 202274993, 196817042, 263324120, 263327661, 263327665, 263324123, 265406984, 265406978, 316366060, 269138792, 269138799, 87660748, 269138796, 269138795, 87660742, 87660761, 198918369, 184747058, 184747048, 87660750, 87660757, 187360834, 87660752, 87660746, 193114167, 187361863, 87660743, 87660756, 87893267, 87893275, 87893277, 814891333, 814891342, 814891332, 814891348] Warning: Incomplete multipolygon relation 11758 (Lago Maggiore): using bbox of unclosed polygon to calc tiles, ways: [339499330, 339499338, 339499332, 339499337, 339499331] Warning: Incomplete multipolygon relation 11758 (Lago Maggiore): using bbox of unclosed polygon to calc tiles, ways: [173660449, 203517579, 203517587, 173660454] Warning: Incomplete multipolygon relation 11758 (Lago Maggiore): using bbox of unclosed polygon to calc tiles, ways: [211154423, 211154912, 366067218, 366067212, 366067214, 366067220, 366067216, 366067222] Warning: Incomplete multipolygon relation 11758 (Lago Maggiore): using bbox of unclosed polygon to calc tiles, ways: [202421534, 202421531] Warning: Incomplete multipolygon relation 11758 (Lago Maggiore): using bbox of unclosed polygon to calc tiles, ways: [202421542, 202421532, 87896545] Warning: Incomplete multipolygon relation 11758 (Lago Maggiore): using bbox of unclosed polygon to calc tiles, ways: [222482940] Warning: Incomplete multipolygon relation 11758 (Lago Maggiore): using bbox of unclosed polygon to calc tiles, ways: [222484904, 87896544, 87894927, 222496706, 222496701, 87894916, 87894926] Warning: Incomplete multipolygon relation 11758 (Lago Maggiore): using bbox of unclosed polygon to calc tiles, ways: [87893287, 186266917, 186266942, 87893262, 814465684] I took a look at OpenStreetMap but I really can’t understand if there is a problem with data and multipolygons. Do you have any idea of how I could solve this problem ? Thank you ! Diego

3 2

Re: [mkgmap-dev] The "Elevation=M" in the header of the polish .MP files does not work
by Vadim Karpov 06 Mar '23

06 Mar '23

Hi all, Thanks a lot for the new build r4907 !!! It works well. But there are problems with the accuracy of the values. Often integers are converted to fractions. Perhaps something with rounding of intermediate fractional values. (.MP)->(.IMG) in meters: 22 -> 21.9 (-0.1) 22.5->22.6 (+0.1) 23->22.9 (-0.1) 23.5->23.5 (=0) 24->24.1 (+0.1) 24.5->24.4 (-0.1) 25->25 (=0) 25.5->25.6 (+0.1) 26->25.9 (-0.1) 26.5->26.5 (=0) 27->27.1 (+0.1) ... Can accuracy be improved? PS: Values of CONTOUR types 0x10900...0x10905 are still not converted according to the ELEVATION=M parameter. :( PPS: It is worth noting that cGPSmapper has the same problems… -- Vadim > >Суббота, 4 марта 2023, 11:23 +03:00 от Gerd Petermann <gpetermann_muenchen(a)hotmail.com>: > >Hi Vadim, > >the code in mkgmap seems to expect int values when elevation is given in m. No idea why, the code is from 2008 and wasn't changed since: > > private void fixElevation() { > if (elevUnits == 'm') { > String h = polyline.getName(); > try { > // Convert to feet. > int n = Integer.parseInt(h); > n *= METERS_TO_FEET; > polyline.setName(String.valueOf(n)); > > } catch (NumberFormatException e) { > // OK it wasn't a number, leave it alone > } > } > } > >I can change that to use double precision but you probably need more changes to support the special types. Maybe you can modify PolishMapDataSource.java >and provide a patch? > >Gerd > > >________________________________________ >Von: mkgmap-dev < mkgmap-dev-bounces(a)lists.mkgmap.org.uk > im Auftrag von Vadim Karpov < bombur(a)mail.ru > >Gesendet: Freitag, 3. März 2023 09:46 >An: Development list for mkgmap >Betreff: Re: [mkgmap-dev] The "Elevation=M" in the header of the polish .MP files does not work > >Hi all! > >Thanks for the new build (r4906) ! >But the problem is only partially solved. > >Integer values (22 or 12) are converted normally. >But fractional ones (for example: 25.5 or 26.25) are still perceived by the compiler as feet. :( > >All values of subtypes 0-5 of marine type 09 (0x10900 … 0x10905) are interpreted exclusively as feet... > >PS: I can't place an example .MP file in this mailing list. I will send it personally. >Четверг, 2 марта 2023, 18:01 +03:00 от Gerd Petermann < gpetermann_muenchen(a)hotmail.com >: > >Hi all, > >OK, I see no problems to change this method in GType.java: > public static boolean isContourLine(MapLine line) { > return line.getType() >= 0x20 && line.getType() <= 0x22 && !(line instanceof MapShape); > } > >All I have to do is to change 0x22 to 0x25, right? > >Gerd > >________________________________________ >Von: mkgmap-dev <mkgmap-dev-bounces(a)lists.mkgmap.org.uk< /compose?To=mkgmap%2ddev%2dbounces(a)lists.mkgmap.org.uk >> im Auftrag von Vadim Karpov <bombur(a)mail.ru< /compose?To=bombur(a)mail.ru >> >Gesendet: Donnerstag, 2. März 2023 14:38 >An: mkgmap-dev(a)lists.mkgmap.org.uk< /compose?To=mkgmap%2ddev(a)lists.mkgmap.org.uk > >Betreff: Re: [mkgmap-dev] The "Elevation=M" in the header of the polish .MP files does not work > >Hi > >Yes. > >Types 0x23.0x24.0x25 are used to create bathymetric maps. > >Information from the MPCTypes.txt file (TypViewer application): > >0x02000=Contour Lines/MINOR_CONTOUR/Minor land-based contour line/Non NT >0x02100=Contour Lines/INT_CONTOUR/Intermediate contour (should be used for about every 5th contour line)/Non NT >0x02200=Contour Lines/MAJOR_CONTOUR/Major contour (should be used for about every 10th contour line)/Non NT > >0x02300=Contour Lines/MINOR_BATHY_CONTOUR/Minor bathymetric, or depth, contour/Non NT >0x02400=Contour Lines/INT_BATHY_CONTOUR/Intermediate bathymetric, or depth, contour (should be used for about every 5th contour line)/Non NT >0x02500=Contour Lines/MAJOR_BATHY_CONTOUR/Major bathymetric, or depth, contour (should be used for about every 10th contour line)/Non NT > >Четверг, 2 марта 2023, 12:01 +03:00 от Ticker Berkin <rwb-mkgmap(a)jagit.co.uk< /compose?To=rwb%2dmkgmap(a)jagit.co.uk >>: > >Hi > >My understanding of the default Garmin usage is that > 0x20..0x22 are land/height contours (Minor to Major) > 0x23..0x25 are sea/depth " " > >Ticker > >On Thu, 2023-03-02 at 08:52 +0000, Gerd Petermann wrote: >> Hi Vadim, >> >> I see code in mkgmap to handle the statement with Elevation=m or >> Elevation=M, but it is only used for the line types 0x20 .. 0x22. >> Do you have a good reason to use line type 0x25 instead? >> >> Gerd >> >> >> ________________________________________ >> Von: mkgmap-dev <mkgmap-dev-bounces(a)lists.mkgmap.org.uk</compose?To=mkgmap%2ddev%2dbounces(a)lists.mkgmap.org.uk< /compose?To=%2fcompose%3fTo%3dmkgmap%252ddev%252dbounces(a)lists.mkgmap.org.uk >>> im Auftrag >> von Vadim Karpov <bombur(a)mail.ru</compose?To=bombur(a)mail.ru< /compose?To=%2fcompose%3fTo%3dbombur(a)mail.ru >>> >> Gesendet: Mittwoch, 1. März 2023 13:00 >> An: mkgmap-dev(a)lists.mkgmap.org.uk</compose?To=mkgmap%2ddev(a)lists.mkgmap.org.uk< /compose?To=%2fcompose%3fTo%3dmkgmap%252ddev(a)lists.mkgmap.org.uk >> >> Betreff: [mkgmap-dev] The "Elevation=M" in the header of the polish >> .MP files does not work >> >> Good afternoon ! >> >> I am using the latest version of MkGMap and trying to create a depth >> chart with isolines (types 0x24, 0x25). >> >> The problem is that the compiler interprets the depth specified in >> Meters as in Feet. >> The result is independent of the presence or value of the >> "Elevation=M" parameter. >> >> And I didn't find an alternative command line option. :( >> >> So how can I tell the compiler to treat all numerical depth and >> height values in an .MP file as meters and not feet? >> >> Thanks for the advice. >> >> PS: cGpsMapper works fine with "Elevation=M" of course. >> PPS: Example of polylyne defs: >> >> [POLYLINE] >> Type=0x02500 >> Label=21 >> EndLevel=3 >> Data0=(47.139263517000003,-122.560520313), ... >> [END] >> >> [POLYLINE] >> Type=0x02500 >> Label=12 >> EndLevel=3 >> Data0=(47.127846400000003,-122.562501059), ... >> [END] >> >> -- >> Vadim Karpov >> _______________________________________________ >> mkgmap-dev mailing list >> mkgmap-dev(a)lists.mkgmap.org.uk</compose?To=mkgmap%2ddev(a)lists.mkgmap.org.uk< /compose?To=%2fcompose%3fTo%3dmkgmap%252ddev(a)lists.mkgmap.org.uk >> >> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > >-- >Vadim Karpov >Отправлено из Почты Mail.ru<https://trk.mail.ru/c/zzm979> > >-- >Vadim Karpov

1 0

Style Syntax for semi- or un-connected Lines
by Felix Herwegh 06 Mar '23

06 Mar '23

Hi, I seem to have difficulties to figure out the correct lines syntax to address semi- or un-connected lines. Using hgh:surface=Race & hgh:WayRel=yes & hgh:WayAcc != yes {set mkgmap:set_semi_connected_type=none; set mkgmap:set_unconnected_type=none} [0x10e05 level 0] still assigns 0x10e05 to roads like https://www.openstreetmap.org/way/815829699, although this is the only type definition assigning 0x10e05. Same for e. g. "set mkgmap:set_semi_connected_type=0x39" instead of "none". (Using Mkgmap version 4896 atm) Since documentation is quite sparse on this: Can somebody please help me out? Thanks, Felix

2 2