<div dir="ltr"><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jan 28, 2022 at 12:04 PM Gerd Petermann <<a href="mailto:gpetermann_muenchen@hotmail.com">gpetermann_muenchen@hotmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Jose,<br>
<br>
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.<br></blockquote><div><br></div><div>Hi Gerd,</div><div><br></div><div>actually I did but the memory column was hidden :-o<br></div><div><br></div><div><img src="cid:ii_kyyg13zf0" alt="obrázok.png" width="486" height="510"></div><div><br></div><div>Thank you - it's lot more useful with this data.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Besides that it is really difficult to answer your questions.<br>
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.<br>
The size required size is that for the RGN data (which discribed the geometry) and the NET data which contains the labels, house numbers<br>
and other data and finally the NOD data which contains routing data.<br>
Garmin uses all kinds of compression methods to reduce redundancy, so it's  difficult to see an effect when you make small changes.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>jose<br></div><div><br></div></div></div>