Re: [mkgmap-dev] Embedding raster maps
Hi Steve, thanks for the file. On my device nothing is visible at all. But that's kind of an information, too. There is no way to circle down bugs by simply skipping the extended part. Probably it is still some missing encoding. In the Isle of Man map (and others) there is much more information in the RGN header. Note the values in the "filling bytes". And there seems to be an additional section after the extended point2 section. I called it offset1/length2. --- RGN header --- size 007D type 47 41 52 4D 49 4E 20 52 47 4E | GARMIN RGN byte0x0000000C 01 flag 00 year 2010 month 7 day 21 hour 9 minute 53 second 6 offset1 0000D54E length1 00000000 offset_polyg2 0000D54E length_polyg2 00001A1F byte0x00000025_0x00000038 02 00 00 00 00 00 00 00 FF 00 00 20 FD FC 03 00 00 00 00 00 offset_polyl2 0000EF6D length_polyl2 00000000 byte0x00000041_0x00000054 00 00 00 00 00 00 00 00 3F 00 00 20 FD 0F 00 00 00 00 00 00 offset_point2 0000EF6D length_point2 00000000 byte0x0000005D_0x00000070 00 00 00 00 00 00 00 00 FF 07 00 20 3F F7 3F 00 00 00 00 00 offset2 0000EF6D length2 0000020B unknown 000000E3 This section has a variable length in different sub-files. The unknown value E3 can be E5, too. It doesn't seem to be a record size. I had a look at several sections. They are not completely random, thus there seem to be no "compression". However the patterns do not ring a bell for me. I copied a couple of them into a file and loaded it into my cloud share: https://www.magentacloud.de/share/s429h1z-r6 Maybe one of you has an idea what it's about. I also uploaded my current version of the test map with a single raster map tile. It does not show. Top left coordinate is N46° 57.768 E011° 47.484. Sadly I am stuck here and I am running out of quality time to concentrate on the topic. I also have to update QMapShack's decoding. While reading the mkgmap source code I noticed a lot of new stuff that is not covered by the decoder. Cheers Oliver
Hi Oliver
thanks for the file. On my device nothing is visible at all. But that's kind of an information, too. There is no way to circle down bugs by simply skipping the extended part.
To be clear, nothing is visible on my device either with that polygon type. Only if I change the type to something else (I used 0x10101) do I see anything. As far as I know extended polygons work in mkgmap and I just assumed that it is a reserved type for the images or something similar.
Probably it is still some missing encoding. In the Isle of Man map (and others) there is much more information in the RGN header. Note the values in the "filling bytes". And there seems to be an additional section after the extended point2 section. I called it offset1/length2.
mkgmap sets all of these to zero and seems to work. Of course it may not work for your purpose with the images. I would try taking a copy of a working map and zeroing out some of the unknown things until it stops working. You will then know if something is essential or not. I have no ideas about what byte0x00000025_0x00000038 could be. They look like bitmaps or flags to me.
Maybe one of you has an idea what it's about. I also uploaded my
I've had a go at displaying this section and I have uploaded a sample to: http://files.mkgmap.org.uk/detail/497 There is an initial part followed by two lists, the first has five byte records and the second 4 bytes. My guess is that the first one is related to polygon types and the second is some kind of index sorted by type or by zoom and/or division. Presumably it points into the extended polygon section, but I do not have anything that displays that section at the moment so I can't yet match anything up. The code I used is in the method RngDisplay::displayRgn5() in the display project. (The particular file is at https://svn.mkgmap.org.uk/mkgmap/display/trunk/src/test/display/RgnDisplay.j...) This works with the files that are available to me, maybe not on anything else :) Cheers, Steve
Hi Steve,
mkgmap sets all of these to zero and seems to work. Of course it may not work for your purpose with the images. I would try taking a copy of a working map and zeroing out some of the unknown things until it stops working. You will then know if something is essential or not.
Done that. Removing the "flags" seem to have no impact. Removing the size of this 5th RGN section does. Therefor it is important :)
Presumably it points into the extended polygon section, but I do not have anything that displays that section at the moment so I can't yet match anything up.
Ok, I will think about it. Just from my understanding also the information how these raster tiles fit into the draw order is missing. Maybe it's hard coded or set by that section. I also noted that QMapShack is probably decoding the extended polylines completely wrong. (Just wonder why no one complained so far ^^ ). I saw in the code that there is some test code. Is there already some way to create a test img for extended polylines and polgons that I can use as a reference to fix my code? This would be of great help. Cheers Oliver
Hi Steve, if I got that right data in RGN5 is like MDR16, means, it contains Huffman decoding data. At least a lot of bytes look similar and GPXSee also gets the decoding data from it. Most of the code that displays MDR16 can be used to read RGN5, too. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Steve Ratcliffe <steve@parabola.me.uk> Gesendet: Donnerstag, 7. Januar 2021 11:31 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Embedding raster maps Hi Oliver
thanks for the file. On my device nothing is visible at all. But that's kind of an information, too. There is no way to circle down bugs by simply skipping the extended part.
To be clear, nothing is visible on my device either with that polygon type. Only if I change the type to something else (I used 0x10101) do I see anything. As far as I know extended polygons work in mkgmap and I just assumed that it is a reserved type for the images or something similar.
Probably it is still some missing encoding. In the Isle of Man map (and others) there is much more information in the RGN header. Note the values in the "filling bytes". And there seems to be an additional section after the extended point2 section. I called it offset1/length2.
mkgmap sets all of these to zero and seems to work. Of course it may not work for your purpose with the images. I would try taking a copy of a working map and zeroing out some of the unknown things until it stops working. You will then know if something is essential or not. I have no ideas about what byte0x00000025_0x00000038 could be. They look like bitmaps or flags to me.
Maybe one of you has an idea what it's about. I also uploaded my
I've had a go at displaying this section and I have uploaded a sample to: http://files.mkgmap.org.uk/detail/497 There is an initial part followed by two lists, the first has five byte records and the second 4 bytes. My guess is that the first one is related to polygon types and the second is some kind of index sorted by type or by zoom and/or division. Presumably it points into the extended polygon section, but I do not have anything that displays that section at the moment so I can't yet match anything up. The code I used is in the method RngDisplay::displayRgn5() in the display project. (The particular file is at https://svn.mkgmap.org.uk/mkgmap/display/trunk/src/test/display/RgnDisplay.j...) This works with the files that are available to me, maybe not on anything else :) Cheers, Steve _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd When I looked at this (not very closely) a couple of weeks ago, it seemed as if LBL could be huffman encoded, with ENCODING_FORMAT set to 11, and the decoding table somewhere in RGN Ticker On Tue, 2022-01-25 at 08:10 +0000, Gerd Petermann wrote:
Hi Steve,
if I got that right data in RGN5 is like MDR16, means, it contains Huffman decoding data. At least a lot of bytes look similar and GPXSee also gets the decoding data from it.
Most of the code that displays MDR16 can be used to read RGN5, too.
Gerd
Hi Ticker, yes, that's right. I am working on an implementation, but it will take a while ... The Huffman table in the Ile of man map is probably used to decode the raster image. I has a symbol width of 32. Just starting to learn how it works, GPXSee is a great help but the code is hard to read. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Dienstag, 25. Januar 2022 09:45 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Embedding raster maps Hi Gerd When I looked at this (not very closely) a couple of weeks ago, it seemed as if LBL could be huffman encoded, with ENCODING_FORMAT set to 11, and the decoding table somewhere in RGN Ticker On Tue, 2022-01-25 at 08:10 +0000, Gerd Petermann wrote:
Hi Steve,
if I got that right data in RGN5 is like MDR16, means, it contains Huffman decoding data. At least a lot of bytes look similar and GPXSee also gets the decoding data from it.
Most of the code that displays MDR16 can be used to read RGN5, too.
Gerd
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi developers, yes, RGN5 contains one or more Huffman decoding sections. For the Ile of man map there is only one table with symbol width 32, in a CN Europe NTU tile I find 5 different tables, two with symbol width 8 and three with 32. A lot more to learn here.. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Dienstag, 25. Januar 2022 09:53 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Embedding raster maps Hi Ticker, yes, that's right. I am working on an implementation, but it will take a while ... The Huffman table in the Ile of man map is probably used to decode the raster image. I has a symbol width of 32. Just starting to learn how it works, GPXSee is a great help but the code is hard to read. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Dienstag, 25. Januar 2022 09:45 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Embedding raster maps Hi Gerd When I looked at this (not very closely) a couple of weeks ago, it seemed as if LBL could be huffman encoded, with ENCODING_FORMAT set to 11, and the decoding table somewhere in RGN Ticker On Tue, 2022-01-25 at 08:10 +0000, Gerd Petermann wrote:
Hi Steve,
if I got that right data in RGN5 is like MDR16, means, it contains Huffman decoding data. At least a lot of bytes look similar and GPXSee also gets the decoding data from it.
Most of the code that displays MDR16 can be used to read RGN5, too.
Gerd
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
participants (4)
-
Gerd Petermann -
Oliver Eichler -
Steve Ratcliffe -
Ticker Berkin