> Two of them are:
>
> 1. At the moment multipolygons are cut into pieces just after reading
> from the input file. The first solution would not move that but the
> multipolygon code does the cutting for each resolution and tags the
> result with mkgmap:resolution=N. So there will be a copy of each polygon
> for each resolution.
> The style converter checks this tag and filters out the objects that
> does not match this resolution.
> The mp cutting code is changed in such a way that it uses the
> RoundCoordsFilter to check if a polygon is visible in the given
> resolution. If not it is not used in this resolution.
>
> This variant seems to be quite easy to implement and gives a good
> impression if that improves the whole story. It is not optimal due to
> the high number of additional polygons that must be kept in memory. But
> for a prototyping test it seems to be great.

Yes, that sounds like a good idea for the start.
I also have some ideas how to improve the cutOutInnerPolygons() method.

>
> 2. The mp cut algorithm could be moved to the resolution dependant
> processing of mkgmap. That's somewhere between the StyledConverter and
> the subdivision splitting. This is a bit cleaner but I am not sure how
> many effort this needs.

Probably a lot more, but maybe I change my mind when I know the code
a bit better.

> I have no idea how to use a TYP file to avoid such problems.
> The algorithm to decide if a mixed are should be displayed as sea or
> land is the resolution dependant mp cut algorithm as described above.
>

Well, I don't yet have an idea how to handle the case when many small
islands cover - lets say - 70% of the area, but all of them are too small
to be displayed. I fear we will only display see in that case.
Anyhow, this problem  has to be solved later.

Gerd