[mkgmap-dev] Work in progress and the mdr2 branch

Thu Feb 10 17:33:35 GMT 2022

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 at lists.mkgmap.org.uk
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev