finding out more about the size taken by elements in generated map
Hello, can someone recommend a way how I can learn more about what the detailed statistics in respect to the byte size of each element in the map generated by mkgmap? What I am looking for is something like: - lines: 3.2 MB - road_class 0: 1.3 MB - road_class 1: 1.2 MB - road_class 2: 0.3 MB .. - points: 1.0 MB - symbol 0x2c04: 0.3 MB - symbol 0x4c00: 0.2 MB Not sure if it makes any sense but the rationale behind is having an tool that would provide some hints as to which map details can be sacrificed when trying to cover the largest area of the map. Thanks, jose
Hi Jose GPSMapEdit from https://www.geopainting.com/ can tell you some of this. The free version should do; install it and open gmapsupp.img or an individual tile. Then look at Map Properties > Statistics tab. Ticker On Thu, 2022-01-27 at 15:31 +0100, jose1711 wrote:
Hello, can someone recommend a way how I can learn more about what the detailed statistics in respect to the byte size of each element in the map generated by mkgmap? What I am looking for is something like: - lines: 3.2 MB - road_class 0: 1.3 MB - road_class 1: 1.2 MB - road_class 2: 0.3 MB .. - points: 1.0 MB - symbol 0x2c04: 0.3 MB - symbol 0x4c00: 0.2 MB Not sure if it makes any sense but the rationale behind is having an tool that would provide some hints as to which map details can be sacrificed when trying to cover the largest area of the map. Thanks, jose _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Thank you, Ticker. I was able to run this program w/o issues even on Linux (via wine). Statistics tab gives quite a shallow view, it is not able to answer questions like: - am I saving any space if I don't include "name" in the point (restaurants without name)? In other words: how much data is used for labels or other attributes. Does it make any sense to use shorter labels or group them (pizza foo and pizza bar becomes "pizza" - will it be reused?) - How many kBs is taken by 50000 footways or 1000 polylines. The count itself is not really helpful - Is there any padding involved so it makes sense to make labels shorter just "enough" to not waste a single byte - Other statistics - data cannot be exported easily (even via clipboard) That means it's still going to be a lot of trial & error (if I do this - am I getting a smaller output and by how much?). On Thu, Jan 27, 2022 at 4:36 PM Ticker Berkin <rwb-mkgmap@jagit.co.uk> wrote:
Hi Jose
GPSMapEdit from
can tell you some of this. The free version should do; install it and open gmapsupp.img or an individual tile. Then look at Map Properties > Statistics tab.
Ticker
On Thu, 2022-01-27 at 15:31 +0100, jose1711 wrote:
Hello, can someone recommend a way how I can learn more about what the detailed statistics in respect to the byte size of each element in the map generated by mkgmap? What I am looking for is something like: - lines: 3.2 MB - road_class 0: 1.3 MB - road_class 1: 1.2 MB - road_class 2: 0.3 MB .. - points: 1.0 MB - symbol 0x2c04: 0.3 MB - symbol 0x4c00: 0.2 MB Not sure if it makes any sense but the rationale behind is having an tool that would provide some hints as to which map details can be sacrificed when trying to cover the largest area of the map. Thanks, jose _______________________________________________ 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
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. 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. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Jozef Riha <jose1711@gmail.com> Gesendet: Freitag, 28. Januar 2022 11:48 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] finding out more about the size taken by elements in generated map Thank you, Ticker. I was able to run this program w/o issues even on Linux (via wine). Statistics tab gives quite a shallow view, it is not able to answer questions like: - am I saving any space if I don't include "name" in the point (restaurants without name)? In other words: how much data is used for labels or other attributes. Does it make any sense to use shorter labels or group them (pizza foo and pizza bar becomes "pizza" - will it be reused?) - How many kBs is taken by 50000 footways or 1000 polylines. The count itself is not really helpful - Is there any padding involved so it makes sense to make labels shorter just "enough" to not waste a single byte - Other statistics - data cannot be exported easily (even via clipboard) That means it's still going to be a lot of trial & error (if I do this - am I getting a smaller output and by how much?). On Thu, Jan 27, 2022 at 4:36 PM Ticker Berkin <rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk>> wrote: Hi Jose GPSMapEdit from https://www.geopainting.com/ can tell you some of this. The free version should do; install it and open gmapsupp.img or an individual tile. Then look at Map Properties > Statistics tab. Ticker On Thu, 2022-01-27 at 15:31 +0100, jose1711 wrote:
Hello, can someone recommend a way how I can learn more about what the detailed statistics in respect to the byte size of each element in the map generated by mkgmap? What I am looking for is something like: - lines: 3.2 MB - road_class 0: 1.3 MB - road_class 1: 1.2 MB - road_class 2: 0.3 MB .. - points: 1.0 MB - symbol 0x2c04: 0.3 MB - symbol 0x4c00: 0.2 MB Not sure if it makes any sense but the rationale behind is having an tool that would provide some hints as to which map details can be sacrificed when trying to cover the largest area of the map. Thanks, jose _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto: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<mailto:mkgmap-dev@lists.mkgmap.org.uk> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
On Fri, Jan 28, 2022 at 12:04 PM Gerd Petermann < gpetermann_muenchen@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
participants (4)
-
Gerd Petermann -
jose1711 -
Jozef Riha -
Ticker Berkin