[Patch] building inside building should not be triggered for hollow buildings

[mkoniecz]

Example: ​osmwww:browse/way/151913827 inside ​osmwww:browse/relation/2052964

Repository Root: http://josm.openstreetmap.de/svn
Build-Date: 2013-11-20 02:34:39
Last Changed Author: Don-vip
Revision: 6394
Repository UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
URL: http://josm.openstreetmap.de/svn/trunk
Last Changed Date: 2013-11-19 02:29:10 +0100 (Tue, 19 Nov 2013)
Last Changed Rev: 6394

Identification: JOSM/1.5 (6394 en_GB) Windows 7 32-Bit
Memory Usage: 84 MB / 247 MB (26 MB allocated, but free)
Java version: 1.7.0_45, Oracle Corporation, Java HotSpot(TM) Client VM
Dataset consistency test: No problems found

Plugin: OpeningHoursEditor (29854)
Plugin: notes (v0.6)

[simon04]

This is due to building=yes being set on the outer way. This causes the code to test containment using the outer ring as it is without the multipolygon relation.

[skyper]

Replying to simon04:

This is due to building=yes being set on the outer way. This causes the code to test containment using the outer ring as it is without the multipolygon relation.

IMO this is an outdated way of tagging. What we probably need is an additional warning about an multipolygon without an primary tag like *way,building,landuse,natural etc.. Adding building=yes to the relation will/should raise a warning about same tags on outer way and relation.

[simon04]

This is not too easy to fix …

[mdk]

This looks very similar to #7034. It looks like a new variation not handled yet.

The problem is definitely the building=yes on the outer way. The missing of any tags in the relation is not responsible for this problem, but for me this looks like a mapping error. Redundant tags on outer way and MP are unnecessary, but no error.

[mdk]

I realized, that the problem is more general. Ignoring multipolygon relations creates some false positives like
outer: natural=wetland (​http://www.openstreetmap.org/way/24543664)
inner: natural=water (​http://www.openstreetmap.org/way/44866110)
relation: type=multipolygon natural=wetland (​http://www.openstreetmap.org/relation/1718903)
warning: Overlapping water areas

Even if I remove all tags from the outer way, I get the same warning!

Same problem with "Overlapping identical landuses". Can somebody explain me, where the problem is in the attached OverlappingIdenticalLanduse.osm file?

Is it possible to list BOTH objects if the validator found a problem between two? In both above cases only the relation is listed. I'm an experienced mapper, but it is hard or even impossible for me to find out, what the problems are.

[akks]

Looking...

[akks]

In OverlappingIdenticalLanduse.osm​ there is a real problem, validator is right: there exist both closed way AND multipoligon on the same area (try Alt-click)

However, I agree that validator should show both (or more overlapped objects).

[akks]

By the way, there are special charachters ⧉ in geometry.mapcss
​http://josm.openstreetmap.de/browser/josm/trunk/data/validator/geometry.mapcss
The look nice in Trac and maybe in some font-rich-Linux distributions, but not in Netbeans or Far Manager :)

[Don-vip]

No problem with Eclipse :) You could open a ticket to Netbeans :)

[akks]

What about special rule or modificator for marking both intersecting objects?
Is it possible with mapcss syntax?
Or maybe we should leave old overlapping tests written in classic Java and use mapcss tests only for markinig single incorrectly placed/tagged objects, not pairs?

[akks]

Maybe offtopic (where to place it?), but

Here is an "intuitive" patch to show both opverlapping or intersecting objects detected with mapcss geometry vaildator.
It make detection of errors like in 6 much easier.

Since I do not fully understand mapcss processing chain (Selectors, Finder, Environment, etc. ), I ask the authors to check and include it in some form :)

[simon04]

In 6773/josm:

see ticket:9361#comment:13 - MapCSS validator: highlight both primitives for spatial tests - patch by akks

[simon04]

Replying to akks:

Since I do not fully understand mapcss processing chain (Selectors, Finder, Environment, etc. ), I ask the authors to check and include it in some form :)

Nice enhancement and patch. :-) I slightly adapted your patch, mainly to fix the test case compile error.

[aceman]

Replying to skyper:

Replying to simon04:
What we probably need is an additional warning about an multipolygon without an primary tag like *way,building,landuse,natural etc...

+1, can we get it?

[Don-vip]

I think this is the same problem as reported in #10037 comments.

[simon04]

The patch is a bit of a hack, but it seems to work for the example in the ticket description.

[bastiK]

The different styles of area tagging (closed way, multipolygon with tags on relation or tags on outer way) make this very messy. As long as we do not have a more abstract concept of an area, this may be the best we can do.

It should probably be

containsFinder = new ContainsFinder(e.withPrimitive(multipolygon)) { 

instead of

e.osm = multipolygon;

Also note that there is now a class OptimizedGeneralSelector which is a base class of GeneralSelector, so should be used instead for instanceof and casting.

[simon04]

Paul, thanks for the feedback. Let's go with this patch for now (with your suggested modification), since it fixes this bug …

[simon04]

In 7169/josm:

fix #9361 - MapCSS: consider multipolygon when matching outer ring of a multipolygon for the ∈ selector