Work in progress and the mdr2 branch
Hi all, during the last days I've mainly rewritten GPXSee code in Java to be able to understand all the new structures in NT format. I am making progress but it will probably take weeks until I really understand any of it. The code in GPXSee is written to be very fast and it silently stops reading whereever bits or bytes have unexpected values, something that we cannot do when we want to be able to write that format. Most confusing for me is that it reads parts of the NOD file backwards (at least I think that is what class BitStream4R does). Anyway, while debugging I see data that looks correct, e.g. some road geometry and labels match the data shown in GPXSee, so I think it's just a matter of time to get to the point where GPXSee is now. I wonder if I should try to merge the mdr2 branch into trunk first? It's major changes so far are: - ability to use Huffman compression MDR15 (the string table in the global PC index *_mdr.img) - different (hopefully better) handling of mixed cased labels (--lower-case option) - changes from the faster-mp branch - possibly more memory needed to write global POI index (mdr11) - default style change to not render natural=coastline as line (*) - reduced I/O because no strings temp file written for gmapsupp index (*) (*) It would be quite easy to do this in trunk as well without merging the rest of the changes Gerd
Hi Gerd I feel there are too many disparate and significant changes in mdr2 to merge it into trunk in 1 go. Is it possible do a topic at a time, starting with the least likely to cause problems, leaving time between for any problem to emerge? Ticker On Thu, 2022-02-10 at 11:35 +0000, Gerd Petermann wrote:
Hi all,
during the last days I've mainly rewritten GPXSee code in Java to be able to understand all the new structures in NT format. I am making progress but it will probably take weeks until I really understand any of it. The code in GPXSee is written to be very fast and it silently stops reading whereever bits or bytes have unexpected values, something that we cannot do when we want to be able to write that format. Most confusing for me is that it reads parts of the NOD file backwards (at least I think that is what class BitStream4R does). Anyway, while debugging I see data that looks correct, e.g. some road geometry and labels match the data shown in GPXSee, so I think it's just a matter of time to get to the point where GPXSee is now.
I wonder if I should try to merge the mdr2 branch into trunk first?
It's major changes so far are: - ability to use Huffman compression MDR15 (the string table in the global PC index *_mdr.img) - different (hopefully better) handling of mixed cased labels (-- lower-case option) - changes from the faster-mp branch - possibly more memory needed to write global POI index (mdr11) - default style change to not render natural=coastline as line (*) - reduced I/O because no strings temp file written for gmapsupp index (*)
(*) It would be quite easy to do this in trunk as well without merging the rest of the changes
Gerd _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Ticker, OK, I can start with the simple changes in style and the gmapsupp index without strings temp file. Next would be the changes from faster-mp branch, maybe next week. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 10. Februar 2022 18:33 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Work in progress and the mdr2 branch Hi Gerd I feel there are too many disparate and significant changes in mdr2 to merge it into trunk in 1 go. Is it possible do a topic at a time, starting with the least likely to cause problems, leaving time between for any problem to emerge? Ticker On Thu, 2022-02-10 at 11:35 +0000, Gerd Petermann wrote:
Hi all,
during the last days I've mainly rewritten GPXSee code in Java to be able to understand all the new structures in NT format. I am making progress but it will probably take weeks until I really understand any of it. The code in GPXSee is written to be very fast and it silently stops reading whereever bits or bytes have unexpected values, something that we cannot do when we want to be able to write that format. Most confusing for me is that it reads parts of the NOD file backwards (at least I think that is what class BitStream4R does). Anyway, while debugging I see data that looks correct, e.g. some road geometry and labels match the data shown in GPXSee, so I think it's just a matter of time to get to the point where GPXSee is now.
I wonder if I should try to merge the mdr2 branch into trunk first?
It's major changes so far are: - ability to use Huffman compression MDR15 (the string table in the global PC index *_mdr.img) - different (hopefully better) handling of mixed cased labels (-- lower-case option) - changes from the faster-mp branch - possibly more memory needed to write global POI index (mdr11) - default style change to not render natural=coastline as line (*) - reduced I/O because no strings temp file written for gmapsupp index (*)
(*) It would be quite easy to do this in trunk as well without merging the rest of the changes
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 (3)
-
Gerd Petermann -
Gerd Petermann
-
Ticker Berkin