stplanr
stplanr copied to clipboard
Overlapping segments in overline
The issue, as I understand it, is shown in the image below:
Discussed with @mem48 (who wrote most of the current implementation) and @wangzhao0217 (who is working on a fix).
@dabreegster (thanks for flagging this), does that match the issues you've spotted? Any ideas for a quick fix welcome. My thinking: post-processing step to break linestrings at every linestring start and end point. Hope that makes sense.
Source of excalidraw image: https://excalidraw.com/#room=992c953a1aade429b1a0,prond81biShX0ms1lb1njQ
A minimal example can be found here: https://github.com/ropensci/stplanr/releases/tag/overlapping_segments_in_overline
Simple reprex based on Robin's example
library(sf)
# Recreate Robin's example
l1 = st_sf(geom = st_sfc(st_linestring(matrix(c(-2,2,
0,0,
0,-2
), ncol = 2, byrow = T))))
l2 = st_sf(geom = st_sfc(st_linestring(matrix(c(2,2,
0,0,
0,-1
), ncol = 2, byrow = T))))
l1$flow = 1
l2$flow = 2
l = rbind(l1,l2)
net = stplanr::overline2(l, "flow")
plot(net) # Incorrect result, due to different end points
# Solution
# Access component data
net2 = stplanr::overline2(l, "flow", simplify = FALSE)
# Find and split overalpping lines
withs = st_within(net2) # We nedd to split Line 2 with line three
splits = net2[lengths(withs) > 1,]
splits = st_cast(splits, "POINT")
# Put back together and overline again
net3 = lwgeom::st_split(net2, splits)
net3 = st_collection_extract(net3, "LINESTRING")
net4 = stplanr::overline2(net3, "flow", simplify = TRUE)
plot(net4) # Correct result
It needs some refinement, the st_split should not be run on the whole dataset for real cases. Thes is also some recursion by running overline twice. Ideally, this would be fixed internally to reduce unneeded runs.
A minimal example can be found here: https://github.com/ropensci/stplanr/releases/tag/overlapping_segments_in_overline
I'm not sure this is the same problem as Robin's example. It seems like there are nearby but not truly overlapping lines. Overline was not designed to fix that kind of problem; it looks for duplicated coordinates. You might need to snap coordinates to a grid to reduce these kinds of overlap.
Work-around using rnet_join() to aggregate to a 'base network' presented in #576
Understanding the root cause is important for sure, but FYI, a fix is not important for NPW -- we switched to generating the route network using an od2net-like approach a few weeks ago. I'm sure you'd want to fix this for the NPT site, but I don't know the urgency of that. The overline methodology for doing this is always going to have correctness and performance challenges; summing counts per road using road IDs that a routing engine already provides is always going to be simpler, less bug-prone, and faster.
Yeah, we're fixing this to improve the route network layer (lots of excess linestrings will affect the performance of the website being a major motivation). Agreed re summing over OSM IDs, as osm2net does, and have opened a new issue to revive the conversation: https://github.com/nptscot/internal/issues/96
Associated repo where we can test this (npt repo is a bit too bloated for these tests, there are issues on that also, refactoring is in order but not a priority): https://github.com/nptscot/od2net-tests
An approach to tackling this would be to use the anime package behind the scenes: https://github.com/JosiahParry/anime/tree/main/r