Modify

Opened 12 months ago

Last modified 11 months ago

#17528 new enhancement

[WIP PATCH] Detect issues at intersections

Reported by: taylor.smock Owned by: team
Priority: normal Milestone:
Component: Core Version:
Keywords: Cc:

Description

There are some issues that should be discovered near intersections.

For example, a short disconnect of road continuity at an intersection or a road has a node very close to another.

In the patch, I'm currently using 5.0 meters for the max distance for road continuity and nearby nodes (it ignores nearby nodes with tag information over 1.0 meters away from an intersection).

Attachments (14)

intersectionissues.patch (8.9 KB) - added by taylor.smock 12 months ago.
Initial patch for finding some intersection issues
IntersectionIssues.osm (4.8 KB) - added by taylor.smock 12 months ago.
Examples of possible issues found by this patch
intersectionissues.2.patch (10.6 KB) - added by taylor.smock 12 months ago.
Add checks to reduce false positives. Now looks for ways that are not flagged under the overlapping ways test and have an angle of less than 30 degrees.
intersectionissues.3.patch (15.3 KB) - added by taylor.smock 12 months ago.
Implement methods to ensure a test occurs after another test. The code that attempts to prevent duplication of overlapping ways is not currently working.
intersectionissues_v2.patch (16.1 KB) - added by taylor.smock 12 months ago.
Ensure that tests have information on previously run tests
IntersectionIssues.2.osm (7.9 KB) - added by taylor.smock 12 months ago.
Update samples
intersectionissues_v3.patch (18.0 KB) - added by taylor.smock 12 months ago.
Filter out items that are not relevant (_links, ways that connect to another short section of with the same ref/name)
intersectionissues_v4.patch (20.0 KB) - added by taylor.smock 12 months ago.
Convert constants to upper case, highlight way segments instead of allowing the entire way to be highlighted, attempt to reduce the amount of false positives.
17528_should_warn.osm (2.7 KB) - added by GerdP 12 months ago.
intersectionissues_v5.patch (19.9 KB) - added by taylor.smock 12 months ago.
Stop ignoring nearly overlapping way segments that have lengths longer than 5m and remove false positives where ways share multiple nodes
intersectionissues_v6.patch (20.2 KB) - added by taylor.smock 12 months ago.
Ignore proposed highways, when looking for almost overlapping ways ignore oneways that have the same name/ref, rename the group from Amost overlapping highways to Sharp angle
intersectionissues_v7.patch (20.9 KB) - added by taylor.smock 12 months ago.
Only highlight the sharp angles of the ways instead of everything touching the intersecting node (it does look much better)
intersectionissues_v8.patch (30.0 KB) - added by taylor.smock 12 months ago.
Add tests along with some modifications to catch some edge cases -- dependent upon #17616, but can be switched back to using GPXDistance methods if necessary.
intersectionissues_v9.patch (37.0 KB) - added by taylor.smock 10 months ago.
Filter out roundabouts for the nearly connected roads check, refactor to reduce method complexities, fix failing tests (I need to use this for awhile to see if there are significant false positives)

Download all attachments as: .zip

Change History (30)

Changed 12 months ago by taylor.smock

Attachment: intersectionissues.patch added

Initial patch for finding some intersection issues

Changed 12 months ago by taylor.smock

Attachment: IntersectionIssues.osm added

Examples of possible issues found by this patch

Changed 12 months ago by taylor.smock

Attachment: intersectionissues.2.patch added

Add checks to reduce false positives. Now looks for ways that are not flagged under the overlapping ways test and have an angle of less than 30 degrees.

comment:1 Changed 12 months ago by GerdP

I wonder how you can find errors produced by OverlappingWays, this test is executed after yours, isn't it?

comment:2 Changed 12 months ago by taylor.smock

Short answer: it isn't (currently) finding those errors. The logic is there, I just need to get it to run after the OverlappingWays test. I haven't seen a way to ensure ordering yet. I'm probably missing it somewhere.

I'm currently testing the overall code (it looks like I probably need to change the minimum angle for one of the tests).

Changed 12 months ago by taylor.smock

Attachment: intersectionissues.3.patch added

Implement methods to ensure a test occurs after another test. The code that attempts to prevent duplication of overlapping ways is not currently working.

comment:3 Changed 12 months ago by GerdP

Don't know if it is relevant here, but we have a plugin called junctionchecking. Sounds like something similar to me.

comment:4 in reply to:  3 Changed 12 months ago by taylor.smock

Replying to GerdP:

Don't know if it is relevant here, but we have a plugin called junctionchecking. Sounds like something similar to me.

Thanks -- I didn't know about that plugin. I'll look into it.

EDIT: It doesn't look like it, but it was crashing on me (see #17534), so it might not be working properly anymore.

Last edited 12 months ago by taylor.smock (previous) (diff)

Changed 12 months ago by taylor.smock

Attachment: intersectionissues_v2.patch added

Ensure that tests have information on previously run tests

Changed 12 months ago by taylor.smock

Attachment: IntersectionIssues.2.osm added

Update samples

Changed 12 months ago by taylor.smock

Attachment: intersectionissues_v3.patch added

Filter out items that are not relevant (_links, ways that connect to another short section of with the same ref/name)

comment:5 Changed 12 months ago by GerdP

I've tried v3 and I think there is a false positive for the junction at node 2202299509.
There are also a lot of warnings for the ways around this area=yes + highway=pedestrian: way 152259055
Not sure if those are intended? The overlapping ways test seems to exclude area=yes ways.
The "zoom to problem" doesn't help much in this case, it would be better to have the WaySegments as highligted objects.
There is also an issue when ways have different layers, see ways connected to https://www.openstreetmap.org/node/3749781035

Besides that please make sure

  • that named constants are written in Upper Case, so maxDistanceNodeInformation should be MAX_DISTANCE_NODE_INFORMATION
  • to use Logging() instead of System.out.printf() and e.printStackTrace();

The test is rather slow but that might be tuned later.

Last edited 12 months ago by GerdP (previous) (diff)

Changed 12 months ago by taylor.smock

Attachment: intersectionissues_v4.patch added

Convert constants to upper case, highlight way segments instead of allowing the entire way to be highlighted, attempt to reduce the amount of false positives.

comment:6 Changed 12 months ago by taylor.smock

I've been trying to figure out how to reduce the false positives. I've taken a look at https://www.openstreetmap.org/node/152259055 and https://www.openstreetmap.org/way/152259055. In the new patch, I don't think either has false positives, but its a work in progress.

It shouldn't be excluding area=yes ways on purpose, but it does exclude all ways that don't have a ref or name tag. I've only ever seen area=yes on pedestrian ways, and most of those don't have names. I can look into it, but I use the ref and name tags to find ways that are relevant to each other.

The printf/e.printstacktrace has been corrected.

Known issues in the current patch:
In the test area (IntersectionIssues.osm), one of the "known bad" intersections isn't found unless it is selected. It is found when it is the only intersection in the test area.

Changed 12 months ago by GerdP

Attachment: 17528_should_warn.osm added

comment:7 Changed 12 months ago by GerdP

Please check 17528_should_warn.osm. With v3 I got a (correct) warning, with v4 it is gone.

Changed 12 months ago by taylor.smock

Attachment: intersectionissues_v5.patch added

Stop ignoring nearly overlapping way segments that have lengths longer than 5m and remove false positives where ways share multiple nodes

comment:8 Changed 12 months ago by GerdP

With v5 I see again more false warnings for places where a road splits, e.g. https://www.openstreetmap.org/node/2202299509
In this case maybe the oneway tags should be checked.

For this node https://www.openstreetmap.org/node/426511161 I think it might make sense to warn about something, maybe "sharp angle".
I don't know this place but it is unlikely that cyclist have to make such a sharp turn.

BTW: I've coded something like this test in for the mkgmap project. The programs warns about sharp angles and somehow fixes them because the Garmin routing algo doesn't like them at all. See https://github.com/openstreetmap/mkgmap/blob/master/src/uk/me/parabola/imgfmt/app/net/AngleChecker.java
No idea if it can help here.

Changed 12 months ago by taylor.smock

Attachment: intersectionissues_v6.patch added

Ignore proposed highways, when looking for almost overlapping ways ignore oneways that have the same name/ref, rename the group from Amost overlapping highways to Sharp angle

comment:9 Changed 12 months ago by GerdP

Somehow the highlighting still doesn't help. 17528_should_warn.osm. I think only the segments which form the sharp angle should be highlighted.

Changed 12 months ago by taylor.smock

Attachment: intersectionissues_v7.patch added

Only highlight the sharp angles of the ways instead of everything touching the intersecting node (it does look much better)

comment:10 Changed 12 months ago by GerdP

Sorry for the late response. I thought I already commented....
It looks better but I still see false positives and I think it would be a good idea to have a unit test similar to MultipolygonTestTestor RelationCheckerTest.

comment:11 Changed 12 months ago by taylor.smock

I still see some false positives and some false negatives as well.

I think I'll see about doing something similar to https://github.com/KaartGroup/highwayNameModificationJOSMPlugin/blob/master/src/com/kaart/highwaynamemodification/GeometryCustom.java in order to get the distance from the node that is almost touching the other way to the other way.

So, TODO list before I work on this particular patch further:

  • Add additional functions to Geometry.java to find the distance between different OSM primitives (I think some addons, namely PT Assistant would also benefit) so I can get the distance between the node and the way. See #17616.
    • Add tests for the above functions
  • Refactor GPXDistance.java to use the new Geometry functions

After that is done, refactor patch to:

  • Take into account the distance of the node from the way
  • Have fewer false positives

Don't worry about taking forever to comment -- I've been working on other stuff as well, which has given me an idea on how to approach #8082.

Last edited 12 months ago by taylor.smock (previous) (diff)

Changed 12 months ago by taylor.smock

Attachment: intersectionissues_v8.patch added

Add tests along with some modifications to catch some edge cases -- dependent upon #17616, but can be switched back to using GPXDistance methods if necessary.

comment:12 Changed 11 months ago by Don-vip

I don't see any mention of the UnconnectedWays test in the discussion. Doesn't this new test produce duplicate results? The descriptions look very similar.

comment:13 Changed 11 months ago by taylor.smock

It (currently) does duplicate some results. From what I understand, UnconnectedWays only looks at nodes that are not connected to any other way, while the test that partially duplicates that particular test (currently called "Disconnected ways" in this patch) looks for intersections where the disconnected ways are separated by a (short) section of road.

comment:14 Changed 11 months ago by Don-vip

OK. Do you want to work more on it to avoid duplication before we merge it?

comment:15 Changed 11 months ago by taylor.smock

Yes. There are still some issues I need to spend time working out.

I've been trying to make certain that the latest version is uploaded in case something permanent happens to me, but as you can tell, I haven't worked on the patch much lately. I've been trying to figure out what is going on with one of my plugins (highwayNameModification), and I haven't been able to figure out why it deadlocks for some length of time, errors, shows a dialog box, and then completes what it was deadlocking on.

Current issues:

1) Flags some roundabouts (I've got to investigate this) in the disconnected ways test (the test was supposed to find intersections where you could go straight across but was drawn in such that you couldn't do that). I think this would be an easy fix (I just have to add a check for a roundabout on the start/end nodes).
2) The nearly overlapping ways (currently called "sharp angle") needs to be redone to use the new methods in Geometry so that there are fewer false positives. I want to find roads that were almost overlapping but were not (the initial test just happened to be looking at sharp angles).
3) One of the tests works when the primitives are selected or it is the only issue in the area (it does work if all primitives are selected). I've got to track this down, but it is an intermittent bug that just won't reproduce itself when I'm stepping through with a debugger.
4) The test cases are currently failing, probably due to (3) -- some tests are getting one less than the expected errors except when I run it under a debugger. I should probably move those checks to a different method.

I should probably pull out the disconnected ways test and put it in the "Way end node near other highway" test, since they are very similar. This would allow me to remove the code that allows some ordering of the tests.

comment:16 Changed 11 months ago by Don-vip

Summary: [PATCH] Detect issues at intersections[WIP PATCH] Detect issues at intersections

OK thank you :)

Changed 10 months ago by taylor.smock

Attachment: intersectionissues_v9.patch added

Filter out roundabouts for the nearly connected roads check, refactor to reduce method complexities, fix failing tests (I need to use this for awhile to see if there are significant false positives)

Modify Ticket

Change Properties
Set your email in Preferences
Action
as new The owner will remain team.
as The resolution will be set.
to The owner will be changed from team to the specified user.
The owner will change to taylor.smock
as duplicate The resolution will be set to duplicate.The specified ticket will be cross-referenced with this ticket
The owner will be changed from team to anonymous.

Add Comment


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

 
Note: See TracTickets for help on using tickets.