Modify

Opened 7 years ago

Closed 7 years ago

#10549 closed defect (wontfix)

False positive: Style for outer way mismatches polygon

Reported by: skyper Owned by: skyper
Priority: normal Milestone:
Component: Core validator Version: latest
Keywords: style polygon Cc: naoliv, bastiK

Description (last modified by 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'

Attachments (2)

poly.osm (899 bytes) - added by skyper 7 years ago.
osm example file
islet-example.osm (1.5 KB) - added by naoliv 7 years ago.
What is the proper tagging for this example then?

Download all attachments as: .zip

Change History (15)

Changed 7 years ago by skyper

Attachment: poly.osm added

osm example file

comment:1 Changed 7 years ago by Don-vip

Cc: naoliv bastiK added

Dupe of #10255 ?

comment:2 Changed 7 years ago by skyper

Description: modified (diff)

comment:3 Changed 7 years ago by skyper

Resolution: duplicate
Status: newclosed

Closed as duplicate of #10255.

comment:4 Changed 7 years ago by 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.

comment:5 in reply to:  4 Changed 7 years ago by skyper

Resolution: duplicate
Status: closedreopened

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

comment:6 Changed 7 years ago by stoecker

Owner: changed from team to skyper
Status: reopenedneedinfo

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.

comment:7 in reply to:  6 ; Changed 7 years ago by 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.

comment:8 in reply to:  7 ; Changed 7 years ago by 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.

comment:9 in reply to:  8 ; Changed 7 years ago by 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.

comment:10 in reply to:  9 ; Changed 7 years ago by 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).

comment:11 in reply to:  10 Changed 7 years ago by 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.

Changed 7 years ago by naoliv

Attachment: islet-example.osm added

What is the proper tagging for this example then?

comment:12 Changed 7 years ago by stoecker

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

comment:13 Changed 7 years ago by stoecker

Resolution: wontfix
Status: needinfoclosed

Wontfix until we get rid of the outer style tagging.

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain skyper.
as The resolution will be set.
The resolution will be deleted.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.