Modify

Opened 4 years ago

Last modified 10 months ago

#3531 reopened defect

Validator - false positives in "way end node near other way"

Reported by: singularita@… Owned by: dmuecke
Priority: normal Component: Core validator
Version: latest Keywords: unconnected_way
Cc: AM909

Description (last modified by mdk)

Check for "way end node near other way" is useful, however in some areas it finds many false positives.

Minimal distance to trigger this warning seems to be 10 (by default).

But what unit it is? when the preference is read, the number is divided by some arbitrary number 6378135.0
What is meaning of that number? No documentation in the source

I've collected some examples of false positives found by validator, along with some ideas how to avoid them:

validator-deadend.png - T-junction near end of way

There is branching (T-junction) close to end of way. This shows false alarm, even though the way in warning is connected to the way with the endnode.

validator-platform.png - Parallel railway tracks or platforms

Railway platforms or tracks running in parallel - these can be as close as 5 meters.
Have some smaller distance to trigger the warning, if both ways (the one with end node and the one close to the node) are parallel or very close to parallel

validator-powerline.png - highway end node close to powerline
validator-stream-road.png - highway end node close to stream

Sometimes features are running quite close to each other "by design".
Power lines often are placed with little regard of what is below them and endpoint of highway ending up near powerline is surely not connected to it.
Sometimes stream run right behind the streets (the streets are ended just before the stream) and they are also not connected

Therefore for "incompatible" features (highway vs waterway, powerline vs waterway/railway/highway) that should not be probably connected
(highway connected to the powerline does not make sense), the distance should be lower too.

I think for these cases, some lower distance threshold (one quarter by default, perhaps ....) should be used

Attachments (6)

validator-deadend.png (2.2 KB) - added by singularita@… 4 years ago.
validator-platform.png (1.9 KB) - added by singularita@… 4 years ago.
Parallel railway tracks or platforms
validator-powerline.png (3.3 KB) - added by singularita@… 4 years ago.
highway end node close to powerline
validator-stream-road.png (817 bytes) - added by singularita@… 4 years ago.
highway end node close to stream
validator_WayEndNodeNearWay_example.osm (1.2 KB) - added by skyper 2 years ago.
example file
falsePositive.osm (1.6 KB) - added by mdk 18 months ago.
It looks like this issue is not so clear, but it huts me every day. So I add a more clear example with a highway near a poweline, a waterway and a barrier. I hope this will help to solve the problem.

Download all attachments as: .zip

Change History (25)

Changed 4 years ago by singularita@…

Changed 4 years ago by singularita@…

Parallel railway tracks or platforms

Changed 4 years ago by singularita@…

highway end node close to powerline

Changed 4 years ago by singularita@…

highway end node close to stream

comment:1 Changed 4 years ago by dmuecke

  • Owner changed from team to dmuecke
  • Status changed from new to assigned

comment:2 Changed 3 years ago by skyper

  • Keywords validator added

I think in all these example there should be a warning as long as the highway does not end with noexit=yes, but it should not be refered to a way with a different layer=* .

Last edited 2 years ago by skyper (previous) (diff)

comment:3 Changed 2 years ago by bastiK

Ticket #4363 has been marked as a duplicate of this ticket.

comment:4 Changed 2 years ago by skyper

  • Component changed from Core validator to Core
  • Keywords way node added

Validator is in Core now

comment:5 Changed 2 years ago by skyper

  • Component changed from Core to Core validator
  • Resolution set to fixed
  • Status changed from assigned to closed

Seems to be fixed

r3992

comment:6 Changed 2 years ago by skyper

  • Resolution fixed deleted
  • Status changed from closed to reopened

Sorry. Validator does not find any "way end node near other way" right now

comment:7 Changed 2 years ago by skyper

I have another example with barrier=fence

Changed 2 years ago by skyper

example file

comment:8 Changed 2 years ago by skyper

Ticket #5837 has been marked as a duplicate of this ticket.

comment:9 follow-up: Changed 2 years ago by skyper

Validator also warns about "way end node near other way" with untagged ways which are only part of landuse-relations as "other way" . Think this is a false positiv, too.

r4074

comment:10 Changed 2 years ago by skyper

Ticket #4257 has been marked as a duplicate of this ticket.

comment:11 in reply to: ↑ 9 Changed 2 years ago by skyper

Replying to skyper:

Validator also warns about "way end node near other way" with untagged ways which are only part of landuse-relations as "other way" . Think this is a false positiv, too.

r4074

Everything except the unntagged way is still an issue. Please, do check the main tag of both ways and filter to only check for ways with the same main tag. Thanks

r4137

comment:12 Changed 2 years ago by skyper

Ticket #5435 has been marked as a duplicate of this ticket.

comment:13 Changed 21 months ago by simon04

Ticket #6313 has been marked as a duplicate of this ticket.

Changed 18 months ago by mdk

It looks like this issue is not so clear, but it huts me every day. So I add a more clear example with a highway near a poweline, a waterway and a barrier. I hope this will help to solve the problem.

comment:14 Changed 18 months ago by mdk

  • Description modified (diff)

Ping :-)

(BTW why dose attaching a file did not effect 'last change date' of the issue in trac?)

comment:15 Changed 18 months ago by simon04

  • Keywords unconnected_way added; validator way node removed

comment:16 Changed 13 months ago by skyper

Found another issue:

a bridge (node) which ends near a landuse=farmland (way)

This should not be a problem (no warning).

EDIT: Already reported in comment:9

Last edited 13 months ago by skyper (previous) (diff)

comment:17 Changed 12 months ago by skyper

Ticket #7742 has been marked as a duplicate of this ticket.

comment:18 Changed 12 months ago by skyper

  • Cc AM909 added

From #7742 AM909:

In r5181:

The validator reports "way node end near other way" when it shouldn't - specifically for objects of different types. Examples:

  • A road (highway=*) that ends near an admin boundary (boundary=administrative + place=city + ...)
  • A road (highway=*) that ends near a river (waterway=river).
  • A road (highway=*) that ends near a power line (power=line). This probably doesn't happen if the power line has layer > that of the road, but few people seem to do this, and the validator doesn't report power lines crossing roads of the same layer, so it is apparently assumed that power lines are layer=6.
  • A fence (barrier=fence) that ends near a road (highway=*).

Basically, it seems this check is designed to find ways that should intersect, but don't. It should, therefore, limit itself to types of ways that should actually intersect (like those with the same main key, though there may be some others).

comment:19 Changed 10 months ago by anonymous

Ticket #7893 has been marked as a duplicate of this ticket.

anonymous:

I often see how the validator reports e.g. a footpath joining a street near a tram line, which leads to said warning. The warning is not correct as connecting a footpath to a railway is wrong. It should not report the warning for such heavily dissimilar ways.

Last edited 10 months ago by skyper (previous) (diff)

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as reopened .
as The resolution will be set. Next status will be 'closed'.
to The owner will be changed from dmuecke. Next status will be 'new'.
Next status will be 'needinfo'.The owner will change to singularita@gmail.com
as duplicate The resolution will be set to duplicate. Next status will be 'closed'.The specified ticket will be cross-referenced with this ticket
Author


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

 
Note: See TracTickets for help on using tickets.