Hi WanMil,
Have you looked at merging adjacent multipolygons?
There was some controversy on the Finnish forum<http:// forum.openstreetmap.org/viewforum.php?id=15> but I was not alone with the opinion that lakes should be defined as multipolygons, no matter how complex they are, and that large map objects can or should be split to avoid problems with tools. Ways can have at most 2000 points, for instance, and rendering tools can merge them as needed.
Currently, Osmarender is flooding Kuopio, even though I did split Lake Saimaa into rather manageable chunks. I guess I should split it further, if the Osmarender bug cannot be fixed easily. But I do not dare to do it now given the strong opposition from one mapper.
I think I devised a reasonable means of identifying artificial cuts between multipolygons, which I also applied to the large multipolygons that I defined, in http://www.openstreetmap.org/browse/changeset/3926233
My artificial cuts are untagged lines that are shared between adjacent multipolygons in role=outer, such as this one between Heposelkä (a section of Lake Saimaa) and the rest of the lake: http://www.openstreetmap.org/browse/way/50841967 Note that the browse window currently shows the main lake as inverted, even though the data appears to be OK in JOSM. Osmarender is having trouble with this small multipolygon too, rendering square-shaped blocks of water where the coastline should be.
Best regards,
Marko
Marko, I don't like artificial cuts. They are not part of the definition of a multipolygon. At the moment mkgmap can process mps serially. There is no chance to detect that there is an artificial cut and that another multipolygon should be merged at this cut (and I don't see any reason why this should be realized. Why should we make it more complicated than needed?!) So in the end what does it mean? The artificial cut will be handled as one segment of the outer polygon and will therefore be tagged with the multipolygon tags. This is the same as happens with all inner cuts by the mp code. From my point of view as long as it isn't widely accepted by the community mkgmap should not implement workarounds that help other tools like Osmarender to work properly. WanMil