Invalid multipolygon or osm2pgsql / rendering issue?

[mboeringa]

I have been looking at a multipolygon discussed on the Dutch section of the OpenStreetMap forums (http://forum.openstreetmap.org/viewtopic.php?pid=386882#p386882 - "Cartierheide bij Eersel")

It is a stretch of natural=heath with a number of inner ways tagged as landuse=forest, and one small patch of natural=water. See image below (and http://www.openstreetmap.org/relation/3393792).

As you can see, 3 of the inner ways aren't displaying, they're blank/white. Zooming in on one of them, and choosing map contents on the site, it shows that this is just normally tagged with landuse=forest, so no reason why it wouldn't display:

I have also been looking at this multipolygon relation in JOSM. I noticed first that the direction of the inner ways are not consistent, some run clockwise, others counter-clockwise. Now this would be a big "no-no" in many spatial data formats, but since for example this Wiki (http://wiki.openstreetmap.org/wiki/Relation:multipolygon) page clearly states that

"direction of the ways _does not matter_"

I think we can safely dismiss this observation as the cause of the rendering issue.

However, I then zoomed in on one the inner ways, in the lower right corner, in JOSM. See the following two images.

It seems this inner way shares a node with the outer way, and thus "touches" it. According to the same Wiki page mentioned above about multipolygon relations

"Inner polygons _must not overlap with outer polygons or touch them_"

which seems to indicate this multipolygon as "_invalid_". Despite this, the relation multipolygon itself renders correctly, just the inner ways don't all render.

Could this "touching" nonetheless be the cause of the problems?

One question that pops up now for me, is where the information for the display of the "map contents" is coming from: since I am able to select the blank/empty inner ways on the main OSM website and get back identification results, I assume osm2pgsql has successfully imported the data in the rendering database, and this "content" is based on the rendering database? _Are these assumptions right?_ I don't know enough technically of the site to interpret this.

If so, this might be rendering error, possibly caused by the touching and maybe an issue interpreting what is inside or outside for such an invalid multipolygon.

Or is the "map contents" data not based on the rendering database, but on the main database (which come to think of it may be more likely, as it shows all relation data...?), and does osm2pgsql fail to import some of these inner ways, likely again because the multipolygon is invalid?

[matkoniecz]

I fixed inner way touching outer one, as it was also incorrect according to aerial images. It failed to fix the reported problem.

[pnorman]

One question that pops up now for me, is where the information for the display of the "map contents" is coming from:

An API map call, it's unrelated to rendering.

osm2pgsql multipolygon conversion issues are out of scope for this tracker.

[mboeringa]

"osm2pgsql multipolygon conversion issues are out of scope for this tracker."

I fully understand, and don't mind if you close the issue based on that, but please confirm or state this particular case is an osm2pqsql issue or multipolygon issue, before doing so.

Since you closed it, I assume you are pointing to osm2pqsql as the most likely cause?

I especially ask this, because from all the discussions I have seen here on the issue tracker, I have understood there is quite some "post-processing" going on in the rendering database before the final display / rendering is reached.

"An API map call, it's unrelated to rendering."

Thanks for explaining.

[matkoniecz]

Multipolygon relation is correct.

[pnorman]

I fully understand, and don't mind if you close the issue based on that, but please confirm or state this particular case is an osm2pqsql issue or multipolygon issue, before doing so.

Since you closed it, I assume you are pointing to osm2pqsql as the most likely cause?

I don't know if it's a valid multipolygon or not. I rather suspect there's a data error, and I'm not sure it's the multipolygon that's in error, but could be something else. The standard next steps for diagnosis would be to download just that area and import it (minding osm2pgsql-dev/osm2pgsql#151), and look at what geometries are in the tables.

So, this could be an osm2pgsql error or a data error, but is almost certainly not an openstreetmap-carto error.

[mboeringa]

The standard next steps for diagnosis would be to download just that area and import it (minding osm2pgsql-dev/osm2pgsql#151), and look at what geometries are in the tables.

I don't have the facilities for that. I may need to post this issue on the osm2pgsql issue tracker, and hope someone else picks it up.

[mboeringa]

OK, I have opened a new issue in the osm2pgsql issue tracker. It is here:

osm2pgsql-dev/osm2pgsql#185

[mboeringa]

I now encountered an October 2013 reported and discussed issue regarding polygons with inconsistent CW and CCW inner holes, like the one in this example, and the effect on rendering results in the mapbox / tilemill Github repository, which seems relevant to this issue? Especially see the extended discussions less related to GeoJSON only, but also PostGIS and Mapnik:

incorrect rendering of holes in GeoJSON polygons #2110
https://github.com/mapbox/tilemill/issues/2110

@pnorman, do you have anything to comment?

Also see this remark by @springmeyer in that same thread issue:

"update: looks like the original patch to Mapnik to support this alternative winding order as part of mapnik/mapnik#450 works, but to avoid artifacts with lines we need to maintain fill_non_zero. Tracking this at mapnik/mapnik#2054."

I am not exactly sure about what is meant with the "artifacts with lines", but this may be of some relevance to you all maintaining the carto-style.

[pnorman]

@pnorman, do you have anything to comment?

None of this matters for openstreetmap-carto or mappers - if there is an issue, which I really doubt, it's elsewhere.