
Hi,
On Fri, Sep 2, 2011 at 9:26 PM, Richard<rz@linux-m68k.org> wrote:
Hi,
I have recently downloaded some mkgmap generated maps that produce this error when displayed in navit: :garmin_obj.c:1279:1|:Error more than 255 polygons/lines in a subdiv are not supported
This does not look like an mkgmap problem to me. Reading the error message I assume that navit does not support subdivisions containing more than 255 polygons + lines. But as far as I know there is no such a limit for garmin devices.
looks like the message comes from libgarmin. If you think its an error in libgarmin I will have a look at that.
The message is indeed from libgarmin, but if someone proves that polygons can be more than 255 fixing wouldn't be so trivial.
255 limit comes from garmin object addressing - in mdr(index file) you have subdiv(2 bytes):object(1 byte). there are references to this in the various sections in img file itself, lbl sections.
If someone have noticed for example that polylines and polygons can be indexed too mdr sections before first poi section describing variuous types available for search seen in an old metroguide map that can fake Lake Someranodmbiglake name.
I tried to check with a simple testcase if more than 255 polygons in one subdivision are supported. But it's not so easy as I expected. I created a single OSM file with 256 lakes (natural=water) close together. But MapSource cuts the lakes on virtual borders around the map and doesn't display them in each zoom level. MapSource is not bugfree but when I see the result of such a simple file I assume there's more wrong with the subdivision handling of mkgmap. Also using less than 256 polygons (e.g. 64) does not give better results. So I cannot give a clear answer till now. WanMil