Not sure where to discuss this, as this refers mainly to openmapchest.org, though this is not really a problem specific to openmapchest, but rather mkgmap and the Garmin.
Openmapchest.org’s USA map is getting close to the 4GB file limit of FAT32. While many of Garmin’s devices can handle multiple files, it would be nice to keep filesizes down.
I was wondering about possible ways to reduce file sizes. One thing that sort of bugged me when looking at the map on my old Garmin nüvi is that parking lots are a total mess. Perhaps there’s a switch to not pass the parking aisles and/or parking lot designators to the gmapsupp.img unless they are directly connected to something that’s not a parking aisle, or only if it’s a public parking lot versus private ones? It would also reduce the number of shapes to draw, though I’m impressed at the render speed of the nüvi as it is.
Maybe there’s some other things that can be done that strips out more extraneous information. I’ve been doing “OCD” (Yes, obsessive-compulsive disorder) edits to try to take out as many superfluous vertices in the roads by merging so that they don’t need to be represented in the gmapsupp.img file, but yeah I know I may be saving at most 8 bytes or so out of the 4GB. But if it’s something that can be done to reduce the size of the file, it would be nice…
Yes, they extract gmapsupp.img for people to use directly. I figure it’s a lot easier than to download all the little pieces and stitch, or planet.pbm and extract them. But wither way, hoping the feedback would be applied to mkgmap or openmapchest.org and get smaller gmapsupp.img.
I would make the edit only if it improves the quality of the OSM database - like removing redundant information which would show up funny when rendered anyway.
This should be a post process deal that the extractor does, but there may be tagging that should be done in the OSM database that helps the extractor know what to omit. Having things tagged incorrectly doesn’t help an extractor know what not to omit.