Validator not showing warning for 'way end node near other highway' for a particular way

[planemad]

What steps will reproduce the problem?

1. Open this area in JOSM ​https://www.openstreetmap.org/node/3612563284 where there is an unconnected residential road near a secondary road
2. Run validator (shift+v) for list of warnings

What is the expected result?

warning for 'way end node near other highway' since the end point is less than a metre from the secondary road

What happens instead?

No warning is displayed

Please provide any additional information below. Attach a screenshot if possible.

If you split the residential road at any point and run the validator again, the warning shows up.

Revision: 8491
Repository Root: http://josm.openstreetmap.de/svn
Relative URL: ^/trunk
Last Changed Author: Don-vip
Last Changed Date: 2015-06-16 23:27:08 +0200 (Tue, 16 Jun 2015)
Build-Date: 2015-06-16 21:45:58
URL: http://josm.openstreetmap.de/svn/trunk
Repository UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last Changed Rev: 8491

Identification: JOSM/1.5 (8491 en) Mac OS X 10.10.3
Memory Usage: 876 MB / 1820 MB (249 MB allocated, but free)
Java version: 1.8.0_51, Oracle Corporation, Java HotSpot(TM) 64-Bit Server VM
VM arguments: [-Djava.security.policy=file:/Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/lib/security/javaws.policy, -DtrustProxy=true, -Djnlpx.home=<java.home>/bin, -Djava.security.manager, -Djnlpx.origFilenameArg=/Users/arun/Library/Application Support/Oracle/Java/Deployment/cache/6.0/56/1ee8cfb8-1b8e9edd, -Djnlpx.remove=false, -Dsun.awt.warmup=true, -Djava.util.Arrays.useLegacyMergeSort=true, -Dmacosx.jnlpx.dock.name=JOSM, -Dmacosx.jnlpx.dock.icon=/Users/arun/Library/Application Support/Oracle/Java/Deployment/cache/6.0/16/47ee53d0-70f4e903.icns, -Djnlp.application.href=https://josm.openstreetmap.de/download/josm.jnlp , -Djnlpx.jvm="/Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/bin/java", -Djnlpx.vmargs=LURqYXZhLnV0aWwuQXJyYXlzLnVzZUxlZ2FjeU1lcmdlU29ydD10cnVlAC1Eam5scC5hcHBsaWNhdGlvbi5ocmVmPWh0dHBzOi8vam9zbS5vcGVuc3RyZWV0bWFwLmRlL2Rvd25sb2FkL2pvc20uam5scCAA]
Dataset consistency test: No problems found

Plugins:
- FastDraw (31265)
- PicLayer (31241)
- ShapeTools (1000)
- buildings_tools (31241)
- dataimport (31241)
- ext_tools (31241)
- geochat (31241)
- geotools (31126)
- jts (31126)
- lakewalker (31241)
- log4j (31231)
- opendata (31241)
- public_transport (31241)
- reltoolbox (31241)
- reverter (31241)
- scripting (30710)
- turnlanes (31241)
- undelete (31241)
- utilsplugin2 (31241)
- wikipedia (31241)

Last errors/warnings:
- W: Failed to scan file 'imagery_offset_db.jar.new' for plugin information. Skipping.
- W: Failed to install plugin '/Users/arun/Library/JOSM/plugins/imagery_offset_db.jar' from temporary download file '/Users/arun/Library/JOSM/plugins/imagery_offset_db.jar.new'. error in opening zip file
- W: Unable to remove primitives from TestError [tester=org.openstreetmap.josm.data.validation.tests.UnconnectedWays$UnconnectedHighways@d791c68c, code=1301, message=Way end node near other highway]
- W: Unable to remove primitives from TestError [tester=org.openstreetmap.josm.data.validation.tests.UnconnectedWays$UnconnectedHighways@d791c68c, code=1301, message=Way end node near other highway]
- W: Unable to remove primitives from TestError [tester=org.openstreetmap.josm.data.validation.tests.UnconnectedWays$UnconnectedHighways@d791c68c, code=1301, message=Way end node near other highway]

[DeeHants]

For reference, 8339, 8491, and 8657 DO flag it, using the default validator.UnconnectedWays.node_way_distance=10.0, and all tests enabled.

[planemad]

Some more info:

• When the data is limited to just the area surruonding the node the warning shows as expected
• When more data of the neighborhood is downloaded and validator is run, the warning disappears

[GerdP]

I can still reproduce the problem with r15336 and also with latest tested version 15322.
Load the attached file and run validator, it doesn't complain about the node which is tagged note=unconnected.
Reason is that method Node.isConnectedTo() finds a connection via the ways 355707467, 355709451, and 281764088.

This method was added to avoid false positives with t-shaped junctions, it also suppresses false positives where short driveways or footways end next to a road. In those cases it probably makes sense, but not in this case.
I'll try to find a better solution.

[GerdP]

My current thinking is this: The method isConnectedTo() should probably be removed or the parameter for "hops" should be reduced from 3 to 1.
I think there are a few cases where it is okay that a highway ends close to another highway:

• the unconnected node has a tag like highway=turning_circle, noexit=yes, entrance=* etc. which means that the way really ends here. This is already implemented.
• they have different values in the layer tag, e.g. a track may end near a bridge
• the way itself is very short and at least one node is connected to a highway
• the node is connected to a building (or maybe very close to one). This is implemented with the patch. Needs more testing.
• a barrier is mapped between the two ways, e.g. a wall, hedge or a waterway. Not easy to detect.

[GerdP]

In 15344/josm:

see #6102, #11778: Improve UNCONNECTED_WAYS test

• avoid to fill QuadBuckets structure with nodes outside downloaded area
• reduce dependence on projection, calculate distance as greatCircleDistance
• check if barrier is between unconnected highways
• don't ignore nodes which are only "connected" via a long detour (4 x mindist), this replaces the method Node.isConnectedTo() which counted hops in a rather unpredictable way.
• fix error in Geometry.addIntersections() which didn't return the intersection node when parameter test was true
• don't report ways with different layer=* values

Test now typically produces a lot more warnings, esp. for sidewalks and for service roads like service=parking_aisle. Not sure if the latter should be supressed...

[stoecker]

Regression (IAE) in #18198.

[GerdP]

I've expected complains about the new methods but got none, so I think this can be closed now.
@team: Sorry, I still cannot set a milestone in the past.