"Fake" inner rings

[wolfbert]

Sorry having to bring this one up here, but it emerged from a discussion with another mapper (and it seems there's no example for this on the wiki).

This is reported by OSMI check "Way in > 1 rings" as an error. My understanding is that osm multipolygons conform to OGC SF except for touching inner rings, which can be combined to form an SF multipolygon. If that is true, then the SF's assertion of

"The interior of a MultiPolygon with more than 1 Polygon is not connected; the number of connected components of the interior of a MultiPolygon is equal to the number of Polygons in the MultiPolygon."

would rule out both cases above. Then again, not all mappers seem to share this view, and I know there's been a lot of discussion about OGC conformance...

[joto]

Interesting case. Never thought about this.

First, case A. I see two possible interpretations of this:

1. The ? area isn't part of any of the (multi)polygons here.
2. The ? area is part of the outer polygon.

I think only (2) is a valid interpretation here. If you merge the two inner polygons, it is clear that the ? area is part of the outer polygon. If you interpret it as (1) this would mean that there is a difference between the case of two inners vs. one inner. That's bad. So (2) is the right interpretation. But I don't think anybody should map something like this!

Now to case B. Here it depends on what roles the gray and yellow ways have. If they have role inner, they form a third inner ring. If they have role outer they make the ? area a part of the outer ring. But this is a contradiction with our generally held opinion that it should be possible to create areas from the ways without looking at the roles! So I think we can not allow this case.

Very tricky all of this. Thanks for bringing this up. I think we might have to amend the "touching inner rings" special rule so that it says something like "all inner rings must fill any hole completely".

[wolfbert]

I haven't seen case B "in the wild" yet, but case A does occur among the "strange" polygons reported by OSMI.

Thinking some more about it, B (1) might work like this:

• MP 1: black outer, red and blue inner (same as if inner is just a single linestring)
• MP 2: blue, green and gray outer
• MP 3: red, green and yellow outer

So MP 2, MP 3 and ? are in the hole of MP 1 and don't have anything to do with it. For B (2), all lines would have to be tagged as inner in MP 1 and assembling them would be ambiguous.

Other interpretations are likely possible. I just don't see a benefit that would be worth the added complexity for mappers and tools.

[mboeringa]

But I don't think anybody should map something like this!

That might be a valid wish, but looking at the particular example of case A here, I think it will actually be a very natural thing to do with the current OSM editor applications. There is three separate closed ways here, which would likely already be there in the map, and all three are subsequently simply added to a multipolygon relation unmodified, with one set to outer, and the other two as inner.

This would be dead easy to create and a quite "natural" thing to do both in JOSM and iD...

[wolfbert]

@joto Actually, this is the price we pay for having touching inner rings. In OGC SF geometry, there are no implicit area declarations, but one area per ring. The seemingly harmless shorthand of touching inner rings has the potential to break this, unless it is - as you suggested - strictly treated as a shorthand (i.e. the union of all touching inner rings has no holes).

@mboeringa You can see some examples in this OSMI view. It seems most mappers have just painted themselves into a corner by subdividing areas with touching inner rings.

What would be a viable way to arrive at a decision?

[mboeringa]

What would be a viable way to arrive at a decision?

What in my opinion should happen is that editor applications like JOSM and iD, in case two candidate inners share one or more common line segment and a user tries to add them to a MP relation, should automatically dissolve / merge the "inners", and set the outline of the newly created dissolved feature as the feature with the inner role of the encompassing MP relation instead of using the inners chosen by the user.

This way, we would never get invalid OGC MP relations like this.

[stoecker]

JOSM interprets case A as two holes inside a full area. The inner part is not excluded and thus part of the outer area style - as Jochen describes it. I also see no reason why it should be different - magically excluding another part only because other inners surround it completely.

Case B is broken anyway. The green lines would have to be added twice and touching inner rings with split sections violate the rule "Exactly two unclosed ways, and no more should share an endpoint". There is no automatic way to resolve the ambiguities.

It may be good to add this example in the documentation, but there is nothing to do to change the definitions.

[mboeringa]

There is no automatic way to resolve the ambiguities.

With my suggestion of the last post, users will be forced to draw a separate outer if they want to see the "?" feature appear as an area part of a multi-part circular multipolygon, because the dissolving of the inners in case A and B would always lead to the two inners turning into a single "inner" for the circular multipolygon, with no automatic creation of an area for candidate feature "?".

I think this is quite unambiguous, and the resulting feature would conform to OGC.

[wolfbert]

@stoecker (Thanks for JOSM, which my mapping depends on.)

It may be good to add this example in the documentation, but there is nothing to do to change the definitions.

As I understand it, case A isn't part of the definition (at least not in the documentation I'm aware of), but excluded. See Relation:multipolygon and Algorithm. Up to now, all rings are nested (tree structure).

[stoecker]

As I understand it, case A isn't part of the definition (at least not in the documentation I'm aware of), but excluded.

The current definition defines inners as holes in the outer area. This discussion centers around the fact if when stamping holes in an area a center piece will also fall out when the holes surround an area. While this is true for a sheet of paper nowhere in the definition of multipolygon there is a suggestion that this is the case.

So the definition we have says that inner are holes and everything not inners are no holes. This includes also the piece which for a real sheet of paper would fall out. There is no need to apply such an assumption to multipolygons (making it only more complex in processing) and also no need to change the way tools are working for a long time now.

Simple solution is to document this case correctly in the wiki and also to recommend not to use it.

Regarding the suggestion to change the editors. Managing code for areas and multipolygons is already a real nightmare - I doubt we will add such handling for the sake of a strange side case which can simply be solved by the processing tools.

The definition of OSM includes touching inners and even after years I still cannot see that this definition is bad, as OSM has not to deal with one area type, but always areas present different styles. The OGC definition may be easier for software, but harder for users and it is automatically convertible, so let the software convert it when required.

[wolfbert]

@stoecker You beat me to it by a few minutes... Case A works in JOSM, case B doesn't, even with the green lines duplicated.

Simple solution is to document this case correctly in the wiki and also to recommend not to use it.

It's used anyway, but in the absence of documentation is questionable. Once it's documented as ok, there we go, and it will cause some weird effects during mapping.
@joto Do you agree with the proposed solution?

On a side note, I find it extremely irritating that we have to spend time discussing this. When tool developers have been aware of that case for a long time now, would it have been asking too much to share that knowledge with mappers and data consumers, given the documentation was obviously incomplete?

[mboeringa]

On a side note, I find it extremely irritating that we have to spend time discussing this. When tool developers have been aware of that case for a long time now, would it have been asking too much to share that knowledge with mappers and data consumers, given the documentation was obviously incomplete?

I am slightly surprised to read such a comment from someone starting a thread on an issue tracker. I usually indulge in these threads to learn something new. Far from irritating.

Anyway, updating documentation is always a good thing, but developers usually are already hard-pressed for time.

Additionally, I doubt anyone could write a truly comprehensive guide of any software as advanced as JOSM clearly is, unless you wish to read a thousand pages before pressing any button...

Managing code for areas and multipolygons is already a real nightmare - I doubt we will add such handling for the sake of a strange side case which can simply be solved by the processing tools.

I fully appreciate the complexity of MP processing in code and understand the reluctance to add more.

Simple solution is to document this case correctly in the wiki and also to recommend not to use it.

It is good to document, but it will likely only have a marginal effect on tagging practice if not prevented or guided by the software. Documentation might help though with fixing efforts like the one @joto started.

[wolfbert]

Additionally, I doubt anyone could write a truly comprehensive guide of any software as advanced as JOSM clearly is, unless you wish to read a thousand pages before pressing any button...

@mboeringa There seems to be a misunderstanding. I do not refer to JOSM documentation at all, but to the multipolygon specs published from 2009 that I referenced further up. There was significant discussion about touching inner rings, and the consequences must have become clear when the software was implemented years ago. Yet, here we are...

Anyway, the whole thing is spilt milk. I'll suggest to update the relevant pages and we'll see what happens.

[stoecker]

@wolfbert: You seems to have an essential misunderstanding of the development of OSM. There was no significant discussion before. Many people discussed later about all the details, but before the feedback was nearly zero.

Frederik proposed a solution to the awful situation we had and I implemented this in JOSM and thus putting a lot of force on the others like the renderers to also support it.

We could have waited with long discussions, but then I assume we wouldn't have a working solution till today. OSM exists because people DID something compared to others DISCUSSING something. And as said I still see no issue with the design we have now - beside that maybe from time to time some finer details like this question here need to be documented properly.

Even the old-style multipolygons could not be prevented, as the implementation did need to care for the incomplete support in tools at this time and tagging the outer ways was the solution for this (remember we even had the "inner=outer polygons" and the "winding order polygons" at that time). I'm happy to get rid of all this now, but I don't think we could have done without it.

It is always easy to lock back - locking forward is hard. And when the stuff we did 8 years ago has so little issues nowadays I'm really proud of what we did.

Beside that: I studied geodesy, so actually I'm a professional in this area and from the very beginning I got told from other professionals that the way OSM works cannot be gone. We have no strict type definitions, no defined property sets, no proper area type, ... So my willingness to listen to standards like OGC was pretty limited at this time. OSM showed that a totally different approach can and does work (also taking into account drawbacks like the database crap resulting from the missing standards).

[wolfbert]

@stoecker Well, for me the issue has been clarified, and anything else that comes to my mind would be better discussed over a beer. These things have a habit of getting out of hand in writing. So, I'll go back to doing 8-)

[mboeringa]

OSM showed that a totally different approach can and does work (also taking into account drawbacks like the database crap resulting from the missing standards).

I think the biggest issue for OSM is not any sub-optimal database design, it is people at times grossly mis-using tags - even when the definition is quite clear from the Wiki - to get stuff rendered on maps.

Additionally, there is still a lack of refinement in tagging in some areas, where additional sub-tags could help filter out and more clearly define features, which would help especially cartographers create more accurate and less cluttered maps.

@stoecker , as you wrote, most other stuff can be dealed with through software, really bad tagging practices are a pain though and often require costly manual intervention.

Anyway, this is all of track for this issue, time for a beer as @wolfbert suggests...

[wolfbert]

Request for documentation update added to Talk:Relation:multipolygon.