False positive: Style for outer way mismatches polygon

[skyper]

Have a look at poly.osm​.

I get a warning about "style for outer way mismatches polygon" with a way for the building and a multipolygon for a café on level zero.

Repository Root: http://josm.openstreetmap.de/svn
Build-Date: 2014-09-23 01:33:40
Last Changed Author: Don-vip
Revision: 7580
Repository UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Relative URL: ^/trunk
URL: http://josm.openstreetmap.de/svn/trunk
Last Changed Date: 2014-09-22 23:20:16 +0200 (Mon, 22 Sep 2014)
Last Changed Rev: 7580

Identification: JOSM/1.5 (7580 en) Linux Debian GNU/Linux 7.6 (wheezy)
Memory Usage: 602 MB / 882 MB (327 MB allocated, but free)
Java version: 1.7.0_65, Oracle Corporation, OpenJDK 64-Bit Server VM
Java package: openjdk-7-jre:amd64-7u65-2.5.1-5~deb7u1
Dataset consistency test: No problems found

Plugins:
- OpeningHoursEditor (30609)
- conflation (0.1.7)
- download_along (30416)
- imagery-xml-bounds (30662)
- jts (30416)
- mirrored_download (30664)
- notes (v0.9.4)
- photoadjust (30428)
- reverter (30521)
- terracer (30643)
- todo (29154)
- undelete (30416)
- utilsplugin2 (30460)
- waydownloader (30664)
- wikipedia (30629)

Last errors/warnings:
- W: Detected deprecated 'canvas{background-color}' in 'https://github.com/bastik/mapcss-tools/raw/osm/mapnik2mapcss/osm-results/mapnik.zip' which will be removed shortly. Use 'fill-color' instead.
- E: Failed to locate image 'null'

[skyper]

osm example file

[Don-vip]

Dupe of #10255 ?

[skyper]

Closed as duplicate of #10255.

[stoecker]

Not a dupe of #10255, but actually the example is NOT valid and the warning correct. Why is there a building=yes on the outer way and nothing more than one way in the relation. For this example, the relation should be killed completely. With more relation elements build=yes should go into the relation.

[skyper]

Replying to stoecker:

Not a dupe of #10255, but actually the example is NOT valid and the warning correct. Why is there a building=yes on the outer way and nothing more than one way in the relation. For this example, the relation should be killed completely. With more relation elements build=yes should go into the relation.

No, the building is the complete building, where as the amenity is only on one floor. Best practice is to split object in these cases to add the corresponding level=* and/or building_levels=*, height=* etc.

The problem is that we have different styles for multipolygon and there is no diversifying by style. See bastiK's comment on #10255

[stoecker]

I still don't see why that example should be valid. The multipolygon consists of an outer way which has a drawing style and an own drawing style. But one area can have only one style. So it's wrong.

Either there should be multiple multipolygons using the same untagged ring or multiple tagged ways overlaying each other to solve this.

[skyper]

Replying to stoecker:

I still don't see why that example should be valid. The multipolygon consists of an outer way which has a drawing style and an own drawing style. But one area can have only one style. So it's wrong.

Well, it does no matter of two multipolygon with same members or one closedway and a multipolygon the renderer has to decide how to display it.

Either there should be multiple multipolygons using the same untagged ring or multiple tagged ways overlaying each other to solve this.

That is new for me. Thought that the relation is independent of any member tag, no matter how many member it has.

[stoecker]

Replying to skyper:

Replying to stoecker:

I still don't see why that example should be valid. The multipolygon consists of an outer way which has a drawing style and an own drawing style. But one area can have only one style. So it's wrong.

Well, it does no matter of two multipolygon with same members or one closedway and a multipolygon the renderer has to decide how to display it.

No. As long as we are with the current status, tags on the outer way are also relevant for the multipolygon. And this is what this test complains about. When one day we can say that this "old style multipolygon" is totally deprecated, then such tagging may be valid. ATM it is not.

Either there should be multiple multipolygons using the same untagged ring or multiple tagged ways overlaying each other to solve this.

That is new for me. Thought that the relation is independent of any member tag, no matter how many member it has.

Not for multipolygon. There the outer tags of ways are relevant. Which tags and which not and in which cases is a heuristic which every tool does different. That's why #10529.

[skyper]

Replying to stoecker:

Replying to skyper:

Replying to stoecker:

I still don't see why that example should be valid. The multipolygon consists of an outer way which has a drawing style and an own drawing style. But one area can have only one style. So it's wrong.

Well, it does no matter of two multipolygon with same members or one closedway and a multipolygon the renderer has to decide how to display it.

No. As long as we are with the current status, tags on the outer way are also relevant for the multipolygon. And this is what this test complains about. When one day we can say that this "old style multipolygon" is totally deprecated, then such tagging may be valid. ATM it is not.

Either there should be multiple multipolygons using the same untagged ring or multiple tagged ways overlaying each other to solve this.

That is new for me. Thought that the relation is independent of any member tag, no matter how many member it has.

Not for multipolygon. There the outer tags of ways are relevant. Which tags and which not and in which cases is a heuristic which every tool does different. That's why #10529.

The ​wiki states that no tags from ways should be used if the relation has tags, so I am a little confused.

[stoecker]

Replying to skyper:

The ​wiki states that no tags from ways should be used if the relation has tags, so I am a little confused.

That's the theory :-) Is "source=" a tag and "comment=" and ... This section was probably written by me before wide usage of this multipolygon was there. Reality is somewhat different.

Probably no tools follows this strict rule (also JOSM not, as we make it depending on the resulting style).

[skyper]

Replying to stoecker:

Replying to skyper:

The ​wiki states that no tags from ways should be used if the relation has tags, so I am a little confused.

That's the theory :-) Is "source=" a tag and "comment=" and ...

That's splitting hairs. These tags are special ones and belong directly to the object.

This section was probably written by me before wide usage of this multipolygon was there. Reality is somewhat different.

So, we need to update the wiki to reflect reality ?!

Probably no tools follows this strict rule (also JOSM not, as we make it depending on the resulting style).

I am, by far, in favour of adding another relation for these cases but if this is the proper way to tag it, I need to change my tagging-style as in my eyes 1:1 overlapping, equal ways are even worse.

[naoliv]

What is the proper tagging for this example then?

[stoecker]

In the future: As is.
Currently: Either a duplicated outer way or two multipolygons or ignoring this warning.

[stoecker]

Wontfix until we get rid of the outer style tagging.