Problems with Russian landuse multipolygons
Hi WanMil, all, Someone has apparently started to import landuse multipolygons in Russia. I keep getting errors for them. Some multipolygons only have "outer" lines. Here are a few examples: http://www.openstreetmap.org/browse/relation/594151 http://www.openstreetmap.org/browse/relation/594273 http://www.openstreetmap.org/browse/relation/595581 http://www.openstreetmap.org/browse/relation/595858 http://www.openstreetmap.org/browse/relation/597112 http://www.openstreetmap.org/browse/relation/597218 http://www.openstreetmap.org/browse/relation/598234 http://www.openstreetmap.org/browse/relation/598527 These are fully within the Geofabrik extract that I have been using. I recently edited the Geofabrik polygon so that no lake multipolygons or natural=coastline islands are severed. Here is one example that is drawn over an existing island multipolygon: http://www.openstreetmap.org/browse/relation/598998 If you download this multipolygon and some surroundings, you should soon get the idea what is wrong with these imports. If the multipolygon handler cannot be made any more robust, then I would appreciate some option that would ignore certain types of multipolygons. Best regards, Marko
Hi WanMil, all,
Someone has apparently started to import landuse multipolygons in Russia. I keep getting errors for them. Some multipolygons only have "outer" lines. Here are a few examples:
http://www.openstreetmap.org/browse/relation/594151 http://www.openstreetmap.org/browse/relation/594273 http://www.openstreetmap.org/browse/relation/595581 http://www.openstreetmap.org/browse/relation/595858 http://www.openstreetmap.org/browse/relation/597112 http://www.openstreetmap.org/browse/relation/597218 http://www.openstreetmap.org/browse/relation/598234 http://www.openstreetmap.org/browse/relation/598527
These are fully within the Geofabrik extract that I have been using. I recently edited the Geofabrik polygon so that no lake multipolygons or natural=coastline islands are severed.
Here is one example that is drawn over an existing island multipolygon:
http://www.openstreetmap.org/browse/relation/598998
If you download this multipolygon and some surroundings, you should soon get the idea what is wrong with these imports.
If the multipolygon handler cannot be made any more robust, then I would appreciate some option that would ignore certain types of multipolygons.
Best regards,
Marko
Hi Marko, I don't understand what your real problem is. Please be more specific (logfile?). The multipolygons I have checked are non conformant to the multipolygon definition. Most of them should be handled ok by the mkgmap multipolygon handler. I don't see where the handler should be more robust (I need a concrete example for that :-) My short comment: We cannot fix bad imports! (we can only try) WanMil
Hi WanMil, On Sun, May 02, 2010 at 12:13:05AM +0200, WanMil wrote:
Hi Marko,
I don't understand what your real problem is. Please be more specific (logfile?).
The multipolygons I have checked are non conformant to the multipolygon definition. Most of them should be handled ok by the mkgmap multipolygon handler. I don't see where the handler should be more robust (I need a concrete example for that :-)
My short comment: We cannot fix bad imports! (we can only try)
Thank you, basically I just wanted to confirm that the data is bad. It would be handy to disable multipolygon processing by some pattern. I guess it would be somewhat of a hack, because multipolygons are processed before executing the style definitions. Marko
0> In article <20100501203241.GA3262@x60s>, 0> Marko Mäkelä <URL:mailto:marko.makela@iki.fi> ("Marko") wrote: Marko> Here is one example that is drawn over an existing island multipolygon: Marko> Marko> http://www.openstreetmap.org/browse/relation/598998 Marko> Marko> If you download this multipolygon and some surroundings, you Marko> should soon get the idea what is wrong with these imports. Relation Analyzer suggests that one of those ways should be "inner", but otherwise thinks it's okay: <URL: http://betaplace.emaitie.de/webapps.relation-analyzer/analyze.jsp?relationId... >
participants (3)
-
Marko Mäkelä -
Toby Speight -
WanMil