Visually deprecate old multipolygon styles

[stoecker]

Currently we still support old styles of multipolygon see ElemStyles.java​. I think it is time to somehow deprecate them more than we do now.

• So probably first is to disable the VERY old method of inner=outer completely.
• second is to never display outer styles for complete multipolygon anymore.
• Third is probably to visually mark the no-style on multipolygons as bad for these cases, where the outers have one common style.

Probably instead of removing code, we can turn it of with a default-false variable?

[stoecker]

According to trunk/data_nodist/multipolygon.osm type 1 (very old) is anyway broken :-)

[stoecker]

Cases 07/01 and 06/03 don't even create a warning ATM. That's broken.

[stoecker]

Unclosed areas (multipolygon or not) should no longer be displayed as proper area. They should be marked somehow.

With proper old-style handling cases 03 and 04 of example should be identical. They are not, so this is also broken ATM.

There should be a real cleanup of area style handling.

[Don-vip]

You may add unit tests that use this file for non-regression :)

[bastiK]

Replying to stoecker:

Currently we still support old styles of multipolygon see ElementStyles.java​. I think it is time to somehow deprecate them more than we do now.

• So probably first is to disable the VERY old method of inner=outer completely.

I think we should remove the very old style completely. This should get rid of some ugly special handling in the code.

• second is to never display outer styles for complete multipolygon anymore.
• Third is probably to visually mark the no-style on multipolygons as bad for these cases, where the outers have one common style.

There are basically two styles in use:

(a) area tags on multipolygon relation
(b) area tags on outer way(s)

If in (b), the tags of the outer ways do not match, this is an error.

The 3rd suggestion I understand that you like to discourage the style (b) somehow. Before we can remove support for this, we should get some kind statistics, how much style (a) and (b) is used overall in the data base and maybe how much it is used in multipolygons that have been created / modified in the last year.

What do you mean by suggestion 2? Surely the outer way can be a highway, so a line style is okay.

[bastiK]

Replying to stoecker:

Unclosed areas (multipolygon or not) should no longer be displayed as proper area. They should be marked somehow.

With proper old-style handling cases 03 and 04 of example should be identical. They are not, so this is also broken ATM.

Aren't they identical? Just the tag is different, so there is a another color.

[stoecker]

Replying to bastiK:

Replying to stoecker:

Currently we still support old styles of multipolygon see ElementStyles.java​. I think it is time to somehow deprecate them more than we do now.

• So probably first is to disable the VERY old method of inner=outer completely.

I think we should remove the very old style completely. This should get rid of some ugly special handling in the code.

Fine with me.

• second is to never display outer styles for complete multipolygon anymore.
• Third is probably to visually mark the no-style on multipolygons as bad for these cases, where the outers have one common style.

There are basically two styles in use:

(a) area tags on multipolygon relation
(b) area tags on outer way(s)

If in (b), the tags of the outer ways do not match, this is an error.

The 3rd suggestion I understand that you like to discourage the style (b) somehow. Before we can remove support for this, we should get some kind statistics, how much style (a) and (b) is used overall in the data base and maybe how much it is used in multipolygons that have been created / modified in the last year.

What do you mean by suggestion 2? Surely the outer way can be a highway, so a line style is okay.

Broken thinking. :-) 2 and 3 boil down to "Never care for area styles on multipolygon outer members". Currently with a default false variable to be able to turn it back.

I think our task as editor is to get cleaner style, so we should not wait for the DB anymore, but start acting. Compatibility phase was long enough. It's deprecated for years now. Based on a request on dev mailinglist some month ago.

So my suggestions would be:

• cleanup
• fix 2 broken validator cases
• check or fix validator: any area draw styles on outer ways should be warnings
• disable handling of "outer" styles for multipolygons
• disable display of unclosed areas (polygon or unclosed ways)

Last 2 should be announced in start page.

I had a look at multipolygon/boundary now again and JOSM's (or also my) secret (or not so secret) steps to cleanup database resulted in major reduction of ambiguities. E.g. exclave/enclave is completely dead. Special cases dropped. Boundary type Multipolygon is dying. So a new task ...

[stoecker]

Replying to bastiK:

Replying to stoecker:

Unclosed areas (multipolygon or not) should no longer be displayed as proper area. They should be marked somehow.

With proper old-style handling cases 03 and 04 of example should be identical. They are not, so this is also broken ATM.

Aren't they identical? Just the tag is different, so there is a another color.

Right. Why the hell did I use different styles for each row? No idea.

[bastiK]

In 7563/josm:

see #10529 - remove "very old" multipolygon style (area tags on both inner and outer ways)
(actually, this was never supported for MapCSS styles)

[bastiK]

This is all I plan to do on this topic for now... :)

[stoecker]

In 7565/josm:

see #10529 - fix one validator test case for multipolygon

[stoecker]

In 7566/josm:

see #10529 - add another test case for inner/outer

[stoecker]

In 7567/josm:

see #10529 - add parameter to disable outer-way styled multipolygons, defaults still to true

[stoecker]

Added a parameter now. Question is how the default value should be.

I didn't find the relevant code yet where I can tell JOSM, that unclosed areas aren't areas. The value "pretendWayIsClosed" seems to be wrong place. Any suggestions where to search?

[stoecker]

In 7568/josm:

see #10529 - fix Javadoc

[bastiK]

Replying to stoecker:

Added a parameter now. Question is how the default value should be.

Had a quick look at two extracts (Hamburg and Corse): With the search terms type:relation type=multipolygon tags:1 and type:relation type=multipolygon I can see that at least 137 out of 351 and 799 out of 1516 multipolygons are tagged with area style at the outer way(s). Suppressing all these with a default value of false seems a bit extreme to me.

I didn't find the relevant code yet where I can tell JOSM, that unclosed areas aren't areas. The value "pretendWayIsClosed" seems to be wrong place. Any suggestions where to search?

The MapCSS specification states that the area selector only applies to closed ways/polygons. I took the liberty to redefine this and allow also unclosed ways, because it has always been like this in JOSM. If you are determined to change this, it would seem reasonable to change the meaning of area back to the standard meaning. This is done ​here for map styles and ​here for the MapCSS Validator rules.

What about incomplete relations, e.g. large forests, where you usually download only a small part of all the polygon ways?

[stoecker]

Replying to bastiK:

Replying to stoecker:

Added a parameter now. Question is how the default value should be.

Had a quick look at two extracts (Hamburg and Corse): With the search terms type:relation type=multipolygon tags:1 and type:relation type=multipolygon I can see that at least 137 out of 351 and 799 out of 1516 multipolygons are tagged with area style at the outer way(s). Suppressing all these with a default value of false seems a bit extreme to me.

A bit too much. You're right. Probably first step is to increase warning to error level in JOSM? OTOH we are in a much better position to improve situation than for example the osm2pgsql guys who would like to have a cleaner state of data :-)

I didn't find the relevant code yet where I can tell JOSM, that unclosed areas aren't areas. The value "pretendWayIsClosed" seems to be wrong place. Any suggestions where to search?

The MapCSS specification states that the area selector only applies to closed ways/polygons. I took the liberty to redefine this and allow also unclosed ways, because it has always been like this in JOSM. If you are determined to change this, it would seem reasonable to change the meaning of area back to the standard meaning. This is done ​here for map styles and ​here for the MapCSS Validator rules.

What about incomplete relations, e.g. large forests, where you usually download only a small part of all the polygon ways?

Yes. It's not so easy. That's why JOSM already implements this "also show partial". For now I think we should have one (or more) hidden option to make display stricter and let's see, what we can do with them. Partial multipolygons probably should still be displayed, but not broken complete data.

[stoecker]

In 7569/josm:

see #10529 - some better warnings for old style multipolygon tagging

[bastiK]

In 7570/josm:

see #10529 - remove duplicate test (same as NO_STYLE_POLYGON)

[bastiK]

In 7571/josm:

see #10529 - raise validator level from information to warning for multipolygons with area style tags at the outer way(s)

[stoecker]

Added a startup note, so users know why they get new warnings.

@bastik:

Im not so sure if "No area style for multipolygon" as "warning" is really a good idea. It will fire for any type which we don't have a style for.

[bastiK]

Replying to stoecker:

Replying to bastiK:

Replying to stoecker:

Added a parameter now. Question is how the default value should be.

Had a quick look at two extracts (Hamburg and Corse): With the search terms type:relation type=multipolygon tags:1 and type:relation type=multipolygon I can see that at least 137 out of 351 and 799 out of 1516 multipolygons are tagged with area style at the outer way(s). Suppressing all these with a default value of false seems a bit extreme to me.

A bit too much. You're right. Probably first step is to increase warning to error level in JOSM?

This test has been at information level so far (so basically invisible). Should be enough to raise it to warning for now (done in [7571]).

I didn't find the relevant code yet where I can tell JOSM, that unclosed areas aren't areas. The value "pretendWayIsClosed" seems to be wrong place. Any suggestions where to search?

The MapCSS specification states that the area selector only applies to closed ways/polygons. I took the liberty to redefine this and allow also unclosed ways, because it has always been like this in JOSM. If you are determined to change this, it would seem reasonable to change the meaning of area back to the standard meaning. This is done ​here for map styles and ​here for the MapCSS Validator rules.

What about incomplete relations, e.g. large forests, where you usually download only a small part of all the polygon ways?

Yes. It's not so easy. That's why JOSM already implements this "also show partial". For now I think we should have one (or more) hidden option to make display stricter and let's see, what we can do with them. Partial multipolygons probably should still be displayed, but not broken complete data.

Instead of switching the rendering off completely, we could also change the drawing in other ways, e.g. somehow mark the point where the area is broken or make the color more transparent, etc.

Same goes for area styles on outer ways: If the color was for example overlayed by a subtle pattern, this would probably bother many people and make them fix the multipolygon tagging.

[bastiK]

In 7572/josm:

see #10529 - fix "typo" in [7571]

[bastiK]

Replying to stoecker:

Added a startup note, so users know why they get new warnings.

@bastik:

Im not so sure if "No area style for multipolygon" as "warning" is really a good idea. It will fire for any type which we don't have a style for.

This was a mistake, thanks.

[stoecker]

What about incomplete relations, e.g. large forests, where you usually download only a small part of all the polygon ways?

Yes. It's not so easy. That's why JOSM already implements this "also show partial". For now I think we should have one (or more) hidden option to make display stricter and let's see, what we can do with them. Partial multipolygons probably should still be displayed, but not broken complete data.

Instead of switching the rendering off completely, we could also change the drawing in other ways, e.g. somehow mark the point where the area is broken or make the color more transparent, etc.

Same goes for area styles on outer ways: If the color was for example overlayed by a subtle pattern, this would probably bother many people and make them fix the multipolygon tagging.

That sounds fine for me. I assume we need support of the core to change the styles accordingly?

[stoecker]

In 7573/josm:

see #10529 - fix wording

[stoecker]

Reference to the source of my "inspiration"

​https://lists.openstreetmap.org/pipermail/dev/2014-June/027910.html

[pnorman]

I'd love to see more valid MPs - in particular, only new-style MPs and old-style MPs where all outers have identical tags and no tags on the relation but type=multipolygon.

An old-style MP with no tags on the relation but type, no tags on the inner and consistent tags on the outers shouldn't be rendered differently as it's perfectly correct and there are no problems parsing it.* I'd prefer a new-style MP, but the old-style one isn't wrong in any way, so shouldn't be rendered differently.

*Aside from the fact that relations are a pain to process and take about 100 times as long per element than ways. Seriously, if you don't need to make a relation, don't.

[stoecker]

Replying to pnorman:

I'd love to see more valid MPs - in particular, only new-style MPs and old-style MPs where all outers have identical tags and no tags on the relation but type=multipolygon.

These warnings are there for a long time already and multipolygons violating them were buggy all the time. I now added new warnings about mismatch between tagged multipolygon and also tagged outer ways.

An old-style MP with no tags on the relation but type, no tags on the inner and consistent tags on the outers shouldn't be rendered differently as it's perfectly correct and there are no problems parsing it.

For you and mapnik and all the other users: Yes. But we are editor developers, we can be a little stricter, e.g. with an UGLY overlay (see comment 25).

• I'd prefer a new-style MP, but the old-style one isn't wrong in any way, so shouldn't be rendered differently.

We can deprecate old style in favor of directly tagged multipolygons. Some years later other tools like osm2pgsql can then drop old-style-support :-)

This old tagging methods have been required backwards support to actually introduce proper multipolygon support at all when Frederik did the proposal and I the JOSM implementation. Also the very-old-style was needed then. Nothing of this is required today, so we can start dropping support step-by-step. I'm pretty sure that if old-style looks ugly in JOSM it's usage will drop dramatically (valdiator warnings also have effects, but not that much).

• Aside from the fact that relations are a pain to process and take about 100 times as long per element than ways. Seriously, if you don't need to make a relation, don't.

I think that's clear.

[bastiK]

Replying to stoecker:

Instead of switching the rendering off completely, we could also change the drawing in other ways, e.g. somehow mark the point where the area is broken or make the color more transparent, etc.

Same goes for area styles on outer ways: If the color was for example overlayed by a subtle pattern, this would probably bother many people and make them fix the multipolygon tagging.

That sounds fine for me. I assume we need support of the core to change the styles accordingly?

Depends what we do exactly.

@Klumbumbus (and others): Do you have any ideas, how this should presented? Sketches and full designs are very welcome!

[Klumbumbus]

Replying to bastiK:

@Klumbumbus (and others): Do you have any ideas, how this should presented? Sketches and full designs are very welcome!

Just to make sure, that I understand it correct: you want to visually display if a multipolygon is old-style (which means all tags on outer and only type=multipolygon on the relation), right?

[bastiK]

Replying to Klumbumbus:

Replying to bastiK:

@Klumbumbus (and others): Do you have any ideas, how this should presented? Sketches and full designs are very welcome!

Just to make sure, that I understand it correct: you want to visually display if a multipolygon is old-style (which means all tags on outer and only type=multipolygon on the relation), right?

Yes, exactly. This and a second completely independent project where we want to make it visually more obvious that an area / a polygon is unclosed.

[Klumbumbus]

Replying to bastiK:

Replying to Klumbumbus:

Replying to bastiK:

@Klumbumbus (and others): Do you have any ideas, how this should presented? Sketches and full designs are very welcome!

Just to make sure, that I understand it correct: you want to visually display if a multipolygon is old-style (which means all tags on outer and only type=multipolygon on the relation), right?

Yes, exactly. This and a second completely independent project where we want to make it visually more obvious that an area / a polygon is unclosed.

I can imagine a red dashed overlay on the outer line, see screenshot

However I'm not sure if completely dropping display of old MPs wouldn't be better. Both would have the same result: old MPs look different from new ones and the mappers start changing to the new style.

[Klumbumbus]

Replying to bastiK:

... we want to make it visually more obvious that an area / a polygon is unclosed.

You already see that the outline is interrupted while the fill-color is still present up to the imaginary line between the two end nodes. Also after the validator ran, it highlights the end nodes with a circle (see screenshot). Don't you think this is enough?
In general I'm not sure if it is a good idea to implement validation features in the main style.

[stoecker]

Validator itself is not enough to really reach the desired goal. It usually is only called for changed objects, which limits the scope a lot. And many people simply ignore it.

The red dash are too normal in my eyes. But validator layer is a good idea. What about overlaying (or under?) thick red lines for old-style multipolygons or full red circles for unclosed area ends?

I did a test today in an area I know and fixed approx. 10 old multipolygons, where two of them have been broken when interpreting the rules strict (mixed tagging). I believe getting rid of the old style completely will reduce such issues a lot.

[Klumbumbus]

Fully downloaded unclosed area styles can also be changed from warning to error level in the validator. This will also lead to more fixing. I think most people try to fix atleast all errors before uploading.

[aceman]

The unclosed segment may be so small (nodes so close together), that nobody will notice it visually and it may even be off-screen. So a validator error and visual uglyfication of the WHOLE AREA of the polygon is something I'd support ;)

[stoecker]

Replying to Klumbumbus:

In general I'm not sure if it is a good idea to implement validation features in the main style.

I agree with that after some consideration. My suggestion would be an "dataquality.mapcss" in core, which is activated by default. This way it is separate from main style, but still default in core. See also #10545.

[stoecker]

Replying to aceman:

visual uglyfication

Nice wording. :-)

[Don-vip]

Replying to bastiK:

In 7563/josm:

see #10529 - remove "very old" multipolygon style (area tags on both inner and outer ways)
(actually, this was never supported for MapCSS styles)

This change broke 4 unit tests:
​http://donvip.fr/jenkins/job/JOSM/1401/testReport/

[Don-vip]

In 7579/josm:

see #10529 - fix mapcss unit test

[Klumbumbus]

Replying to stoecker:

My suggestion would be an "dataquality.mapcss" in core, which is activated by default. This way it is separate from main style, but still default in core. See also #10545.

Sounds good. Likely we can reuse some of the rules in https://josm.openstreetmap.de/browser/trunk/data/validator and just replace the "throwWarning:..." by a nice ugly style.

[Klumbumbus]

Replying to aceman:

The unclosed segment may be so small (nodes so close together), that nobody will notice it visually and it may even be off-screen. So a validator error and visual uglyfication of the WHOLE AREA of the polygon is something I'd support ;)

A suggestion for a style:

(made with fill-image with this image: )

[aceman]

Looks awfully good :) However, would it be possible to NOT apply this while the user is drawing the polygon so it is obviously unclosed? Only apply it after he removes focus from the object? I worry this could obstruct the imagery layer he is drawing onto, e.g. tracing some houses/area.

[Klumbumbus]

Replying to aceman:

Looks awfully good :) However, would it be possible to NOT apply this while the user is drawing the polygon so it is obviously unclosed? Only apply it after he removes focus from the object? I worry this could obstruct the imagery layer he is drawing onto, e.g. tracing some houses/area.

I was just thinking nearly the same. During editing multipolygons, they are often unclosed or otherwise broken until you are done with your edits. If the error style bothers to much, the mappers will just deactivate it permanetaly which would be bad. I think the error styles should have high opacity.

[pnorman]

A change like this should probably be announced and discussed on a wider scale than the JOSM issue tracker. Does someone want to summarize it?

[stoecker]

Replying to pnorman:

A change like this should probably be announced and discussed on a wider scale than the JOSM issue tracker. Does someone want to summarize it?

No. It's still JOSM developers, who develop JOSM and not a community. We are happy about feedback, but we are no democratic institution.

[stoecker]

Replying to aceman:

Looks awfully good :)

Same here. I'd use this for old-style multipolygons. But maybe it's to much and we should only do a smaller overlay over the lines (e.g. twice as thick as the PNG).

However, would it be possible to NOT apply this while the user is drawing the polygon so it is obviously unclosed?

Yes, that's nothing for unclosed polygons (think about partial ones as well). For unclosed ones I would simply mark the open ends with larger circles. That helps without disturbing.

I'd say let's implement it (non-default), test it, get some outside feedback and then decide whether it gets active or not.

[bastiK]

Replying to stoecker:

Replying to Klumbumbus:

In general I'm not sure if it is a good idea to implement validation features in the main style.

I agree with that after some consideration. My suggestion would be an "dataquality.mapcss" in core, which is activated by default. This way it is separate from main style, but still default in core. See also #10545.

Good idea, I like it!

[stoecker]

Anyone able to make that style - first with:

• unclosed way endpoint markers
• ugly overlay for oldstyle outer ways

Actually I still have not yet had a look at how mapcss is done :-(

[bastiK]

No time, sorry.

[stoecker]

Replying to bastiK:

No time, sorry.

You're in the same club :-)

[Klumbumbus]

Replying to stoecker:

Anyone able to make that style - first with:

• ugly overlay for oldstyle outer ways

the code could look like:

relation[type=multipolygon][!natural][!landuse][!amenity][!tourism][!shop][!leisure][!waterway][!boundary][!building][!landcover][!place][!man_made][area!=yes]::old_MP {
    fill-image: "???/diagonal_wider.png";
    fill-opacity: 0.15;
}

I made a new image for this (), which is less obtrusive. I think the fill opacity should not be higher than 0.15. A problem with this is, that the fill image hides untagged inners (see screenshot).

• unclosed way endpoint markers

There are several problems to implement this in mapcss. First is #10299 and second is that you cannot check within mapcss if a multipolygon relation is closed or not. Atleast I couldn't find a way.

I think there are a lot of more or less complex situations, which are not possible to handle in mapcss. Therfore I think in general the best would be to let the ​validator tests do the calculation if there is an error and then it creates classes or properties of the objects which then simply can be used in mapcss to create the style.
Example:

node.endnode_of_unclosed_area::unclosed_area {
    symbol-size: 16;
    symbol-shape: circle;
    symbol-stroke-color: red;
    symbol-stroke-width: 1;
    symbol-stroke-opacity: 0.8;
}

Would that be possible?

[stoecker]

Would that be possible?

Yes. I'd prefer that. These checks should not be done in mapcss, but in the core and only displayed.

[Klumbumbus]

The code for the ​overpass turbo wizard, if you want to search for old multipolygons in your region:

type:relation and type=multipolygon and natural!=* and landuse!=* and amenity!=* and tourism!=* and shop!=* and leisure!=* and waterway!=* and boundary!=* and building!=* and landcover!=* and place!=* and "man_made"!=* and area!=yes

[Don-vip]

status of this?

[stoecker]

Nothing new. We still need backend support for the necessary pseudo-classes.

[Don-vip]

move tickets that have not been treated this month to next milestone

[stoecker]

Move one month.

[simon04]

In 8237/josm:

see #10529 - MapCSS: add :unclosed_multipolygon pseudo-class and >:open_end selector to go from relations to their open end nodes

For example, relation:unclosed_multipolygon >:open_end node matches open end nodes of unclosed multipolygon relations.

[Klumbumbus]

:unclosed_multipolygon should not trigger for incomplete downloaded multipolygons.

[simon04]

In 8252/josm:

see #10529 - MapCSS: :unclosed_multipolygon should not trigger for incomplete multipolygons

[simon04]

@Klumbumbus: Would you add the desired visual styles?

[Klumbumbus]

I think it is better to add the visual style in the next milestone. Such a big change of the default style should have some more testing time and maybe user feedback until it is part of JOSM-stable.

Open issues are:

• fill image hides untagged ways (inners or outers of MPs are often untagged ways)
• find a better way than in comment:56 to select old style multipolygons (tags on outer instead of relation)
  • maybe a pseudoclass that is true for relations, which are an "area" by the definition of JOSM. so the code could be:

relation[type=multipolygon]!:area::old_MP {
    fill-image: ".../diagonal_wider.png";
    fill-opacity: 0.15;
}

[Don-vip]

skip milestone 15.06

[Don-vip]

Milestone renamed

[Don-vip]

Removing from milestone as it seems nobody's working on it right now.

[stoecker]

Jochen Topf started MapRoulette challenges (​http://area.jochentopf.com/fixing.html) to get rid of the old stuff. Probably that makes this ticket obsolete. :-)

[Stereo]

On the gripping hand, that kind of style would make the challenge easier to solve :-)

[Klumbumbus]

I see only a challenge "Self-Intersecting Multipolygon Relations" not something about old style multipolygons (tags on outer instead of on relation).

[stoecker]

Click on the top left link to see the complete picture. ☺️

[stoecker]

The Git project has a pretty good description:

• Background: ​https://github.com/osmlab/fixing-polygons-in-osm/blob/master/doc/background.md
• Diary: ​https://github.com/osmlab/fixing-polygons-in-osm/issues/15
• Project: ​http://area.jochentopf.com/
• Stats: ​http://area.jochentopf.com/stats/

[stoecker]

In 11782/josm:

see #10529 - increase important multipolygon problems to error level, better separate output of boundary and multipolygon

[stoecker]

In 11908/josm:

see #10529 - don't display outer-way-style multipolygons by default - next step is to remove the related code completely

[stoecker]

When the old style is gone there is a new question: What to do with area styles on outer ways in the future.

The correct definition for OSM will be, that area styles on outer ways are independent. Anyway I think that this is very complex and will lead to many complications. It is also seldom useful. Hopefully OSM definition will discourage usage of this.

Handling in JOSM would be very complicated, as selecting the outer way of a multipolygon does often mean to display or handle the multipolygon itself in different ways/aspects.

My suggestion would be to leave the current implementation, which drops display of an area way style in case the way is an outer member of a multipolygon.

Essentially I suggest to discourage but not prevent area styles on outer ways. Comments?

[aceman]

An example: ​https://www.openstreetmap.org/way/374073526

[aceman]

Replying to stoecker:

The correct definition for OSM will be, that area styles on outer ways are independent. Anyway I think that this is very complex and will lead to many complications. It is also seldom useful. Hopefully OSM definition will discourage usage of this.

Handling in JOSM would be very complicated, as selecting the outer way of a multipolygon does often mean to display or handle the multipolygon itself in different ways/aspects.

When the OSM wiki specifies this change, JOSM can do what you propose. So then you propose drawing another enclosing way (even on the same nodes) and this one gets the tags that would be on the outer way of the multipolygon (e.i. the staduim tags from my example) ?

[stoecker]

In 12026/josm:

see #10529 - drop code completely