Merging adjacent multipolygons
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
On 25 Feb 2010, at 24:09 , Marko Mäkelä wrote:
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.
Osmarender has problems with mp on the tile boundary of a rendered area. you can check the tile size at zoom level 12 to see if the lake crosses it. It happens even for very small mp but it doesn't happen all time.
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 _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Apollinaris,
Osmarender has problems with mp on the tile boundary of a rendered area. you can check the tile size at zoom level 12 to see if the lake crosses it. It happens even for very small mp but it doesn't happen all time.
Thank you for your insight. At http://www.openstreetmap.org/?lat=62.896&lon=27.6889&zoom=12&layers=0B00FTF the coastlines are crossing such tile boundaries. Saimaa is a huge lake, even after me splitting the waters :-) I reported this issue at http://wiki.openstreetmap.org/wiki/Osmarender/Development because I knew no better place. I would not yet split the multipolygon further if it is clearly a tool issue. Mapnik and OpenCycleMap look fine, but it is currently unclear if they are is drawing the water from old coastline-based shape files or from the multipolygon definitions. Best regards, Marko
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
Hi WanMil,
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.
That is not a big deal with artificially split natural=water multipolygons, as the border lines of the lake will be the same colour as the lake. (And I do not think that there any other huge multipolygons than lakes.)
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.
It is not just rendering tools, but editing tools and the OSM server. I tried to view the history of one of the multipolygons that I created, and the server timed out, repeatedly. OSM just does not scale if there are thousands of 500-node ways in a relation. I guess this means that I will be relying on generate-sea in the future. If someone wants to create lake multipolygons for the remaining huge lakes in Finland (for example if they want to tag islands), that is up to them. I have been considering "glueing" artificial natural=coastlines to "seal" the Geofabrik Finland extract, to avoid flooding with generate-sea. Do you have any suggestion how to do this efficiently? Optimally, splitter would input two files, my coastline-glue.osm and the finland.osm.bz2 from Geofabrik. Marko
Hi WanMil,
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.
That is not a big deal with artificially split natural=water multipolygons, as the border lines of the lake will be the same colour as the lake. (And I do not think that there any other huge multipolygons than lakes.)
Ok, this is true for your style. But other renderes might use another color for the outlines. E.g. have a look at the cycle map (http://www.openstreetmap.org/?lat=47.39361&lon=13.65131&zoom=15&layers=00B0F...) you see a green line through the forest which is a segmented multipolygon.
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.
It is not just rendering tools, but editing tools and the OSM server. I tried to view the history of one of the multipolygons that I created, and the server timed out, repeatedly. OSM just does not scale if there are thousands of 500-node ways in a relation.
I guess this means that I will be relying on generate-sea in the future. If someone wants to create lake multipolygons for the remaining huge lakes in Finland (for example if they want to tag islands), that is up to them.
I have been considering "glueing" artificial natural=coastlines to "seal" the Geofabrik Finland extract, to avoid flooding with generate-sea. Do you have any suggestion how to do this efficiently? Optimally, splitter would input two files, my coastline-glue.osm and the finland.osm.bz2 from Geofabrik.
Marko
I don't know very much about the generate-sea option. The code is 95% undocumented (and therefore it takes a long time to get familiar with it). I just got in touch with it because it generates a multipolygon if you set generate-sea=multipolygon. If you want to use your own coastline file you could use a special tag (e.g. natural=markocoastline) and then change the generate-sea source code to use this tag instead of natural=coastline. Before starting mkgmap you might append the content of your coastline file to the geofabrik file. WanMil
participants (3)
-
Apollinaris Schoell -
Marko Mäkelä -
WanMil