Some issues with crossing operator ⧉

[naoliv]

I don't remember if there is a ticket about this, sorry.

1)
Validate example1.osm and see two warnings inside Overlapping Identical Natural Areas: 2 ways: A, B and another with 2 ways: B, A

A, B is the same as B, A, and only one message should be displayed (instead 2, as we see now)
The order should not matter here.

2)
Validate example2.osm and see:

There is no warning about the overlapping ways B, C (we should be seeing 3 warnings here: A, B, A, C, B, C)

JOSM:

URL:http://josm.openstreetmap.de/svn/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2017-01-25 02:17:36 +0100 (Wed, 25 Jan 2017)
Build-Date:2017-01-25 02:33:55
Revision:11490
Relative:URL: ^/trunk

Identification: JOSM/1.5 (11490 en) Linux Debian GNU/Linux 9.0 (stretch)
Memory Usage: 273 MB / 10206 MB (64 MB allocated, but free)
Java version: 1.8.0_111-8u111-b14-3-b14, Oracle Corporation, OpenJDK 64-Bit Server VM
Screen: :0.0 1600x900, :0.1 1280x1024
Maximum Screen Size: 1600x1024
Java package: openjdk-8-jre:amd64-8u111-b14-3
Java ATK Wrapper package: libatk-wrapper-java:all-0.33.3-13
VM arguments: [-Dawt.useSystemAAFontSettings=on]
Program arguments: [--language=en]
Dataset consistency test: No problems found

[Don-vip]

First point is #12627

[naoliv]

Oh, really sorry for the duplicate part.

[Don-vip]

In 11493/josm:

see #12627, see #14289 - add non regression unit tests

[GerdP]

I've created a patch for #14287 which also seems to solve this problem:

[GerdP]

In 15064/josm:

fix #12627,#14287,#14289,#17695

• let CrossingFinder and ContainsFinder find all objects instead of stopping at first match
• if objects are selected, make sure that ContainsFinder is called for enclosing objects which are not in the selection
• enable corresponding unit tests

Draw back: MapCSSTagChecker is a bit slower.

[Don-vip]

Replying to GerdP:

Draw back: MapCSSTagChecker is a bit slower.

How much?

[GerdP]

Depends on the data. In most situations it will not matter. With lots of complex ways the additional intersection tests might have an effect. I have some ideas how to improve performance, I guess that will be more important when I add support for multipolygons to the CrossingFinder.

[GerdP]

Reg. performance: just to make it clearer:
"let CrossingFinder and ContainsFinder find all objects instead of stopping at first match"
The normal case is that CrossingFinder and ContainsFinder do NOT find a match, so that all tests are performed. The special case is that a match is found and only in that situation the old algo stopped earlier.
So, for the validator the expected effect is very small. A different situation is the search dialog.
If you have a dataset with very complex, complete multipolygons and use a mapcss search with e.g.

*[building] ∈ area[natural]

(finds buildings inside natual area)
the search will take much longer when there are many such buildings. The reason is that the Geometry.isPolygonInsideMultiPolygon() is very slow in this case. (working on it now...)

"if objects are selected, make sure that ContainsFinder is called for enclosing objects which are not in the selection"
This adds additional loops to search for objects and filter duplicates. Hard to say how big the effect is.

[GerdP]

Oops, I was wrong. The search

*[building] ∈ area[natural]

finds natural areas with a building inside. So, for this case it would be okay to stop the search on the first match, on the other hand the result seems wrong to me, so probably nobody uses this search.