Re: [mkgmap-dev] The "Elevation=M" in the header of the polish .MP files does not work

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@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@lists.mkgmap.org.uk > im Auftrag von Vadim Karpov < bombur@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@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@lists.mkgmap.org.uk< /compose?To=mkgmap%2ddev%2dbounces@lists.mkgmap.org.uk >> im Auftrag von Vadim Karpov <bombur@mail.ru< /compose?To=bombur@mail.ru >> Gesendet: Donnerstag, 2. März 2023 14:38 An: mkgmap-dev@lists.mkgmap.org.uk< /compose?To=mkgmap%2ddev@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@jagit.co.uk< /compose?To=rwb%2dmkgmap@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@lists.mkgmap.org.uk</compose?To=mkgmap%2ddev%2dbounces@lists.mkgmap.org.uk< /compose?To=%2fcompose%3fTo%3dmkgmap%252ddev%252dbounces@lists.mkgmap.org.uk >>> im Auftrag von Vadim Karpov <bombur@mail.ru</compose?To=bombur@mail.ru< /compose?To=%2fcompose%3fTo%3dbombur@mail.ru >>> Gesendet: Mittwoch, 1. März 2023 13:00 An: mkgmap-dev@lists.mkgmap.org.uk</compose?To=mkgmap%2ddev@lists.mkgmap.org.uk< /compose?To=%2fcompose%3fTo%3dmkgmap%252ddev@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@lists.mkgmap.org.uk</compose?To=mkgmap%2ddev@lists.mkgmap.org.uk< /compose?To=%2fcompose%3fTo%3dmkgmap%252ddev@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
participants (1)
-
Vadim Karpov