-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
API questions #1
Comments
Not for use cases I've seen. In cases where you had 2 different directions, e.g. for morning and afternoon rush hour, you could run |
For sure. |
Not that I know of. There would have to be grade separated parallel geometries on top of each other for that to happen, unusual enough (and I think in breach of OSM guidelines) to not worry about is my guess. |
Any examples of that on OSM? Given the use case is deciding where to invest, and a single piece of infrastructure at one level can take people where they want to go, I think the risk of incorrect policy conclusions arising from this is vanishingly small. |
OK progress on another example, generated by ATIP. Imagine 2 people going from ITS to the Chemic Tavern and then 1 person going from the University of Leeds Union to the skate park. If those are the only trips that take place in the universe, how many people travel on different parts of the network? Resulting GeoJSON below, I plan to make this into an example:
|
Heads-up @dabreegster when you get back to a computer, the commit above adds example data and code that generates this simple example that I think answers your question in the original post: |
Incidentally, looking at the help, impressive already at this nascent stage:
|
Reproducible example just tested showing that the Rust version does not currently handle that scenario well, as far as I can tell the outputs are all zero despite the inputs being 1 to 3:
Will commit that test asap. |
Correction: the Rust version seems to do fine in this example. Just realised though that this test is not the same as the test you mentioned because both input datasets have vertices there. I'm not sure how the R version handles the version you describe. Output showing IMO correct Rust output below and fix in commit below. Reason for issue: |
Update: the example you specific above seems to fail for the R version as shown in the fully reproducible example below. As I mentioned I suspect there are some edge cases where the R version does not work as it should and this could be one of them, were the red line should be split at the vertices: # Test example with 2 lines parallel for some of the way:
library(sf)
#> Linking to GEOS 3.11.1, GDAL 3.4.3, PROJ 8.2.1; sf_use_s2() is TRUE
#> WARNING: different compile-time and runtime versions for GEOS found:
#> Linked against: 3.11.1-CAPI-1.17.1 compiled against: 3.10.2-CAPI-1.16.0
#> It is probably a good idea to reinstall sf, and maybe rgeos and rgdal too
library(stplanr)
line1 = sf::st_linestring(matrix(c(0, 1, 0, 0), ncol = 2))
line2 = sf::st_linestring(matrix(c(
0.2, -0.1,
0.2, 0,
0.8, 0,
0.8, 0.1
), ncol = 2, byrow = TRUE))
plot(line1, col = "red", lwd = 9)
plot(line2, col = "blue", lwd = 5, add = TRUE) lines_without_shared_vertices = sf::st_sfc(line1, line2)
lines_without_shared_vertices_sf = sf::st_sf(geometry = lines_without_shared_vertices)
lines_without_shared_vertices$value = c(1, 2)
lines_without_shared_vertices_overline = overline(sl = lines_without_shared_vertices_sf, attrib = "value")
#> Error in `[.data.frame`(x, i, j, drop = drop): undefined columns selected Created on 2023-04-09 with reprex v2.0.2 |
Thanks for clarifying and generating test inputs! #9 and #10 will cover this.
3 and "3" are very different in GeoJSON; the caller should be sure to pass in numeric properties. Relatedly, I notice lots of the geojson files that maybe come from the |
Does the output need to distinguish direction? If two inputs cross the same roads in opposite directions, do we keep those as separate or not?
What should happen to the blue bit here?
The black line only has two points, but the red input splits it at a few points. Presumably we want to split the black line at the red points, too. Relatedly, are there any known edge cases with bridges/tunnels that might get grouped together incorrectly? Imagine two lines on top of each other, but with different z-levels. Those should not get grouped, in my mind. Maybe there needs to be an option to consider some attribute on the input as a unique grouping key? Or maybe if we group by OSM way ID or similar, that happens for free anyway.
The text was updated successfully, but these errors were encountered: