Re: [mkgmap-dev] Bogus warnings about intersected ways in multipolygons
I don't think these warnings are bogus. Mkgmap definitely has problems with multipolygons. The Languedoc-Roussillon extract (southern France) from Geofabrik provokes about a hundred of these warnings. But I believe that the intersected ways are being generated by mkgmap and that the OSM data is OK. Mkgmap-r1475 did not have this problem but r1502 and r1507 both do. I am unable to pinpoint more accurately when the behaviour changed because I do not have copies of the relevant releases. Perhaps r1494 could be put back on the web site, in the hope that we might have the benefit of the fixes to generate-sea without the multipolygon problems. Exactly where the problems show up can depend on where the tiles are split. One example is at http://www.openstreetmap.org/?lat=43.4047&lon=3.5107&zoom=13&layers= B000FTF as seen on Lambertus' site. Take a look at his tile 63240406.img dated 20-01-2010. If you look at the vineyards (land-use polygons) in the vicinity of Pinet, you will see an obvious straight edge which is spurious, and areas where the inside and outside of the polygon have swapped over.
Hi Adrian,
I don't think these warnings are bogus. Mkgmap definitely has problems with multipolygons. The Languedoc-Roussillon extract (southern France) from Geofabrik provokes about a hundred of these warnings. But I believe that the intersected ways are being generated by mkgmap and that the OSM data is OK. Mkgmap-r1475 did not have this problem but r1502 and r1507 both do. I am unable to pinpoint more accurately when the behaviour changed because I do not have copies of the relevant releases. Perhaps r1494 could be put back on the web site, in the hope that we might have the benefit of the fixes to generate-sea without the multipolygon problems.
Exactly where the problems show up can depend on where the tiles are split. One example is at http://www.openstreetmap.org/?lat=43.4047&lon=3.5107&zoom=13&layers= B000FTF as seen on Lambertus' site. Take a look at his tile 63240406.img dated 20-01-2010. If you look at the vineyards (land-use polygons) in the vicinity of Pinet, you will see an obvious straight edge which is spurious, and areas where the inside and outside of the polygon have swapped over.
The new MP code has a problem with inner polygons that touch the outer. What you say makes me think that whenever the splitter splits an inner polygon it's going to cause trouble because it splits outers/inners along the same line so they will always intersect then. Whaddyathink WanMil? Mark
Hi Adrian,
I don't think these warnings are bogus. Mkgmap definitely has problems with multipolygons. The Languedoc-Roussillon extract (southern France) from Geofabrik provokes about a hundred of these warnings. But I believe that the intersected ways are being generated by mkgmap and that the OSM data is OK. Mkgmap-r1475 did not have this problem but r1502 and r1507 both do. I am unable to pinpoint more accurately when the behaviour changed because I do not have copies of the relevant releases. Perhaps r1494 could be put back on the web site, in the hope that we might have the benefit of the fixes to generate-sea without the multipolygon problems.
Exactly where the problems show up can depend on where the tiles are split. One example is at http://www.openstreetmap.org/?lat=43.4047&lon=3.5107&zoom=13&layers= B000FTF as seen on Lambertus' site. Take a look at his tile 63240406.img dated 20-01-2010. If you look at the vineyards (land-use polygons) in the vicinity of Pinet, you will see an obvious straight edge which is spurious, and areas where the inside and outside of the polygon have swapped over.
The new MP code has a problem with inner polygons that touch the outer.
What you say makes me think that whenever the splitter splits an inner polygon it's going to cause trouble because it splits outers/inners along the same line so they will always intersect then.
Whaddyathink WanMil?
Mark
Two things to remember: It is the point of view to say "the OSM data is OK". The Geofabrik dumps contain incomplete ways and incomplete relations. To get a 100% correct handling of multipolygons if is required to have complete data or to get the shape of the OSM dump. At the moment we have betwixt and between. So on the shape boundary where osmosis cuts the dumps we cannot do a lot at the moment. The 2nd point is a known problem of the current mp code if inner and outer polygons have overlapping lines. This may produce problems (although I haven't tried to reproduce it). But from my experience this won't happen most of the time on tile borders. Certainly the splitter puts the last point of a way inside the bounds to the tile and sometimes the next (or some) point(s) outside the bounds. The ways are not cut exactly on the tile border. So I expect rare situations where inner and outer way contain overlapping ways due to the splitter. Adrian: I want to check the tile from Lambertus. Can you give the download link? I haven't found it. WanMil
Am 25.01.2010 23:03, schrieb WanMil:
Hi Adrian,
I don't think these warnings are bogus. Mkgmap definitely has problems with multipolygons. The Languedoc-Roussillon extract (southern France) from Geofabrik provokes about a hundred of these warnings. But I believe that the intersected ways are being generated by mkgmap and that the OSM data is OK. Mkgmap-r1475 did not have this problem but r1502 and r1507 both do. I am unable to pinpoint more accurately when the behaviour changed because I do not have copies of the relevant releases. Perhaps r1494 could be put back on the web site, in the hope that we might have the benefit of the fixes to generate-sea without the multipolygon problems.
Exactly where the problems show up can depend on where the tiles are split. One example is at http://www.openstreetmap.org/?lat=43.4047&lon=3.5107&zoom=13&layers= B000FTF as seen on Lambertus' site. Take a look at his tile 63240406.img dated 20-01-2010. If you look at the vineyards (land-use polygons) in the vicinity of Pinet, you will see an obvious straight edge which is spurious, and areas where the inside and outside of the polygon have swapped over.
The new MP code has a problem with inner polygons that touch the outer.
What you say makes me think that whenever the splitter splits an inner polygon it's going to cause trouble because it splits outers/inners along the same line so they will always intersect then.
Whaddyathink WanMil?
Mark
Two things to remember:
It is the point of view to say "the OSM data is OK". The Geofabrik dumps contain incomplete ways and incomplete relations. To get a 100% correct handling of multipolygons if is required to have complete data or to get the shape of the OSM dump. At the moment we have betwixt and between. So on the shape boundary where osmosis cuts the dumps we cannot do a lot at the moment.
The 2nd point is a known problem of the current mp code if inner and outer polygons have overlapping lines. This may produce problems (although I haven't tried to reproduce it). But from my experience this won't happen most of the time on tile borders. Certainly the splitter puts the last point of a way inside the bounds to the tile and sometimes the next (or some) point(s) outside the bounds. The ways are not cut exactly on the tile border. So I expect rare situations where inner and outer way contain overlapping ways due to the splitter.
Adrian: I want to check the tile from Lambertus. Can you give the download link? I haven't found it.
WanMil
I forgot some things: The mp code will throw away multipolygons on the tile border * if the outer polygon is not closed AND * if the non closed outer polygon could not be closed by simply connecting last and first point without intersecting itself In case an outer polygon intersects an inner polygon on the artificially added closing segment the mp code should ignore this. If it doesn't - it is a bug :-) WanMil
On 25.01.2010 23:03, WanMil wrote:
It is the point of view to say "the OSM data is OK". The Geofabrik dumps contain incomplete ways and incomplete relations. To get a 100% correct handling of multipolygons if is required to have complete data or to get the shape of the OSM dump.
The "intersected ways" warning appears when working on a planet file splitted by mkgmap as well. This is not a problem specific to the geofabrik dumps.
On Mon, Jan 25, 2010 at 09:39:56PM +0000, Adrian wrote:
I don't think these warnings are bogus. Mkgmap definitely has problems with multipolygons. The Languedoc-Roussillon extract (southern France) from Geofabrik provokes about a hundred of these warnings. But I believe that the intersected ways are being generated by mkgmap and that the OSM data is OK.
That is what I meant by "bogus": the input data is correct, and mkgmap is doing something wrong. The browse URL that I posted was for a block house in Helsinki, nowhere near my tile boundaries. Marko
On Mon, Jan 25, 2010 at 09:39:56PM +0000, Adrian wrote:
I don't think these warnings are bogus. Mkgmap definitely has problems with multipolygons. The Languedoc-Roussillon extract (southern France) from Geofabrik provokes about a hundred of these warnings. But I believe that the intersected ways are being generated by mkgmap and that the OSM data is OK.
That is what I meant by "bogus": the input data is correct, and mkgmap is doing something wrong. The browse URL that I posted was for a block house in Helsinki, nowhere near my tile boundaries.
Marko
Marko, I tried to reproduce your problem but I wasn't able to. I downloaded the geofabrik dump of finnland of today and run splitter on it with the default settings. Then I started mkgmap (current trunk version) and no warning for the multipolygon 5828 was issued. Here is the log for the processing of mp 5828. 2010/01/26 18:46:45 FEIN (MultiPolygonRelation): Construct multipolygon http://www.openstreetmap.org/browse/relation/5828 2010/01/26 18:46:45 FEIN (MultiPolygonRelation): outer http://www.openstreetmap.org/browse/way/22467513 2010/01/26 18:46:45 FEIN (MultiPolygonRelation): inner http://www.openstreetmap.org/browse/way/22467516 2010/01/26 18:46:45 INFO (MultiPolygonRelation): Processing multipolygon http://www.openstreetmap.org/browse/relation/5828 2010/01/26 18:46:45 FEIN (MultiPolygonRelation): Joined 4611686018427388656 with 22467513 2010/01/26 18:46:45 FEIN (MultiPolygonRelation): Joined 4611686018427388657 with 22467516 2010/01/26 18:46:45 FEIN (MultiPolygonRelation): createContainsMatrix listSize: 2 2010/01/26 18:46:45 FEIN (MultiPolygonRelation): check polygon 0 2010/01/26 18:46:45 FEIN (MultiPolygonRelation): check polygon 1 2010/01/26 18:46:45 FEIN (MultiPolygonRelation): createMatrix for 2 polygons took 0 ms 2010/01/26 18:46:45 FEIN (MultiPolygonRelation): Containsmatrix 2010/01/26 18:46:45 FEIN (MultiPolygonRelation): {1} 2010/01/26 18:46:45 FEIN (MultiPolygonRelation): {} WanMil
Hi WanMil, thank you for having a look. On Tue, Jan 26, 2010 at 07:05:39PM +0100, WanMil wrote:
On Mon, Jan 25, 2010 at 09:39:56PM +0000, Adrian wrote:
I don't think these warnings are bogus. Mkgmap definitely has problems with multipolygons. The Languedoc-Roussillon extract (southern France) from Geofabrik provokes about a hundred of these warnings. But I believe that the intersected ways are being generated by mkgmap and that the OSM data is OK.
That is what I meant by "bogus": the input data is correct, and mkgmap is doing something wrong. The browse URL that I posted was for a block house in Helsinki, nowhere near my tile boundaries.
Marko
Marko,
I tried to reproduce your problem but I wasn't able to.
Me neither. It must have been bad map extract then, even though I can't immediately see how. I tried to check the history of the relation and the ways back then, but it could be that someone had moved a node and back again so that the dump was bad but the live data looked OK. I did not check the history of each node. Or then again, this may have been fixed in mkgmap r1512, which I ran today. For what it is worth, this the only message that I could find in my logs about 5828: 2010/01/23 14:24:02 SEVERE (MultiPolygonRelation): Multipolygon http://www.openstreetmap.org/browse/relation/5828 contains intersected ways Here is another case for you: 2010/01/26 13:08:41 SEVERE (MultiPolygonRelation): Multipolygon http://www.openstreetmap.org/browse/relation/48542 contains intersected ways The ways do not really intersect, but they overlap. It is a Japanese garden (leisure=garden) within a landuse=residential polygon. Could you omit the warning for this case, or at least replace the "intersected" with "overlapping"? ASCII art for the lines: RRRRRRRRRRggggRRRRRRRR R g g R R g g R RRRRRRRRRRggggRRRRRRRR R=residential, g=garden. I believe that you would get a similar situation if a "more valid" multipolygon were cut by a tile boundary (T), like this: RRRRRRRRRRRRRRRRRRRRRR R R R gggg R R g g R TTTTTTTTTTTTTTTTTTTTTT R g g R R gggg R RRRRRRRRRRRRRRRRRRRRRR As far as I understand, you'd have to replace the TTTTTTTTTTTTTTTTTTTTTT with RRRRRRRRRRggggRRRRRRRR in each tile. I would not like to see any multipolygon warnings at tile boundaries. I understand that it is currently impossible to silence them at the unknown boundaries of the Geofabrik extracts, but I do get some warnings at tile-splitter boundaries too. Would it be possible to silence them or somehow indicate that they occur at a tile border, so that I can filter out the warnings? Best regards, Marko
Am 26.01.2010 20:00, schrieb Marko Mäkelä:
Hi WanMil,
thank you for having a look.
On Tue, Jan 26, 2010 at 07:05:39PM +0100, WanMil wrote:
On Mon, Jan 25, 2010 at 09:39:56PM +0000, Adrian wrote:
I don't think these warnings are bogus. Mkgmap definitely has problems with multipolygons. The Languedoc-Roussillon extract (southern France) from Geofabrik provokes about a hundred of these warnings. But I believe that the intersected ways are being generated by mkgmap and that the OSM data is OK.
That is what I meant by "bogus": the input data is correct, and mkgmap is doing something wrong. The browse URL that I posted was for a block house in Helsinki, nowhere near my tile boundaries.
Marko
Marko,
I tried to reproduce your problem but I wasn't able to.
Me neither. It must have been bad map extract then, even though I can't immediately see how. I tried to check the history of the relation and the ways back then, but it could be that someone had moved a node and back again so that the dump was bad but the live data looked OK. I did not check the history of each node. Or then again, this may have been fixed in mkgmap r1512, which I ran today. For what it is worth, this the only message that I could find in my logs about 5828:
2010/01/23 14:24:02 SEVERE (MultiPolygonRelation): Multipolygon http://www.openstreetmap.org/browse/relation/5828 contains intersected ways
Here is another case for you:
2010/01/26 13:08:41 SEVERE (MultiPolygonRelation): Multipolygon http://www.openstreetmap.org/browse/relation/48542 contains intersected ways
The ways do not really intersect, but they overlap. It is a Japanese garden (leisure=garden) within a landuse=residential polygon. Could you omit the warning for this case, or at least replace the "intersected" with "overlapping"? ASCII art for the lines:
RRRRRRRRRRggggRRRRRRRR R g g R R g g R RRRRRRRRRRggggRRRRRRRR
R=residential, g=garden. I believe that you would get a similar situation if a "more valid" multipolygon were cut by a tile boundary (T), like this:
RRRRRRRRRRRRRRRRRRRRRR R R R gggg R R g g R TTTTTTTTTTTTTTTTTTTTTT R g g R R gggg R RRRRRRRRRRRRRRRRRRRRRR
As far as I understand, you'd have to replace the TTTTTTTTTTTTTTTTTTTTTT with RRRRRRRRRRggggRRRRRRRR in each tile.
I would not like to see any multipolygon warnings at tile boundaries. I understand that it is currently impossible to silence them at the unknown boundaries of the Geofabrik extracts, but I do get some warnings at tile-splitter boundaries too. Would it be possible to silence them or somehow indicate that they occur at a tile border, so that I can filter out the warnings?
Best regards,
Marko
I analyzed the logfiles and found a possible reason. I got the warnings for http://www.openstreetmap.org/browse/relation/10251. I created GPX files for this relation which is quite useful for analyzation purposes. The GPX files showed that the whole relation was outside the tile bounds and at least one point was missing in the outer polygon. However the outer polygon was closed. So the warning was correct but not useful in any way. The relation was completely contained in another tile so it was rendered and handled correctly later on. I have started to implement a better strategy on the tile boundaries. This will take some time until it is ready for commit. The other problem with the japanese garden can be fixed. The algorithm must allow overlaying polygons. At the moment I see some performance issues for this, but I will have to test it. Maybe there is no issue. As you proposed I will change and reduce the warnings shortly. Thanks for your comments! WanMil
participants (5)
-
Adrian -
Mark Burton -
Marko Mäkelä -
Ralf Kleineisel -
WanMil