When running mkgmap with default setting (or equally, downloading a precomputed map from www.freizeitkarte-osm.de) I notice that points in polygons are very imprecise. This is most obviously seen for small buildings that end up being far from rectangular.
If I read the mkgmap code correctly, points are stored as a 24bit integer and an optional 1byte extension for “high precision” that is only used some of the time. 24bit give a step width of ~2m at the equator and ~1m at 60 degrees north (which is where I live). Visually the drawn shapes look like each point might have an error of up to 1m around here.
Is it plausible that mkgmap indeed doesn’t use the high precision option for polygons, but does use it for lines, such as streets? Is there a command line option to change that? I’m not entirely sure why it wouldn’t be used, but if the reason is storage space in the final map, I’d much prefer smaller errors and a larger map file.
AFAIR that’s due to OSM is more precise than Garmin allows and therefore you will have rounding differences for each node. That’s leading to those artefacts.
There is certainly some rounding going on – I hadn’t considered this might be a requirement of the garmin image format. Do you know if there is any, possibly reverse engineered, documentation of the binary format of those image files?
I spent some more time reading the code: there is indeed a maximum precision of 24bit for one coordinate, and for more zoomed-out zoom levels fewer bits will be used. Based on the comments in the code (Zoom.java), I trust that this is a fundamental limitation of the image format. Or at the very least a limitation of an older version of the image format.
The reason why I thought this only applied to polygons is probably the higher curvature, while indeed all coordinates are affected.
Yes, the limit is in the old IMG format. I think the newer format allows up to 32 bit precision for some objects.
There is code in mkgmap which tries to keep the geometry of small objects like buildings intact. This code sometimes decides to move points a little bit so that rectangular objetcts don’t degrade to triangles. It also helps with parallel lines like rails.
I’ve no familiarity with the innards of mkgmap, but have noticed effects similar to the one that you mention.
I guess my question to you would be - does it look plausible within the code to change that? If you did, how much larger would the resulting files be?** Would the resulting .img files be compatible with a range of Garmin devices and software afterwards?
** size is a problem for some people - the maximum effective .img file size is 4GB, which does limit the area that you can include on one map.
The high precision is an mkgmap internal handling. At the beginning of mkgmap, all OSM coordinates where rounded to 24 bit precision first and that value was stored in memory and used for all further calculations. I noticed that we have 8 unusued bits in the data structure that is used to store one point and so I added code to keep 30 bits precision for all internal calculations.
I don’t know any way to store the higher precision in the old IMG format and I was lost in complexity when I started to analyse the newer format(s)
I haven’t tried to write higher precision coordinates to an image, even with a new format I would be surprised if it was possible to just change that. Based on what Gerd writes the new format is anything but simple. (And I have bricked a device before with a broken map, but that’s a different story.)
Size wise, I think it is reasonable to assume that most storage goes into layer-0, most space is coordinates, and going from 3 to 4 byte per coordinate might increase the total size by 20-30%.