[mkgmap-dev] finding out more about the size taken by elements in generated map
From Jozef Riha jose1711 at gmail.com on Fri Jan 28 13:43:10 GMT 2022
On Fri, Jan 28, 2022 at 12:04 PM Gerd Petermann < gpetermann_muenchen at hotmail.com> wrote: > Hi Jose, > > you probably didn't scroll to the right in the statistics view. Also note > that you can select if you want to see the data for one level or all levels. > Hi Gerd, actually I did but the memory column was hidden :-o [image: obrázok.png] Thank you - it's lot more useful with this data. > > Besides that it is really difficult to answer your questions. > Labels are deduplicated, so each different label is only saved once in an > IMG and the objects with that label are storeed with a ref. > The size required size is that for the RGN data (which discribed the > geometry) and the NET data which contains the labels, house numbers > and other data and finally the NOD data which contains routing data. > Garmin uses all kinds of compression methods to reduce redundancy, so > it's difficult to see an effect when you make small changes. > Thank you also for this piece - I kinda suspected the deduplication is happening. Together with the compression it's likely not worth much to exclude names when squeezing the map size then. jose -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20220128/5adc2582/attachment-0001.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: obr?zok.png Type: image/png Size: 50564 bytes Desc: not available URL: <https://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20220128/5adc2582/attachment-0001.png>
- Previous message: [mkgmap-dev] finding out more about the size taken by elements in generated map
- Next message: [mkgmap-dev] Commit r4880: styleManual-20220126.patch by Ticker Berkin:
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the mkgmap-dev mailing list