Skip to content
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

Intersections "strict/nonstrict" #12

Closed
denadai2 opened this issue Nov 30, 2016 · 3 comments
Closed

Intersections "strict/nonstrict" #12

denadai2 opened this issue Nov 30, 2016 · 3 comments

Comments

@denadai2
Copy link

Hello, I think it would be awesome to have a function/mode to "clean" intersections like this:

screen shot 2016-11-30 at 13 42 18

Since I make spatial inferences in neighbourhoods, I'm more interested on the real-world concept of intersection, rather that the OSM one. So it would be awesome to have the intersections with a buffer of n meters. (In the example this would count as "1" intersection)
What do you think?

@gboeing
Copy link
Owner

gboeing commented Nov 30, 2016

I think it's a good idea for urban design studies. I've been playing around with a method for that, in fact, as part of my dissertation work. At this point I'm not including it in OSMnx itself because it requires a bunch of additional heavyweight packages for a limited use case. But, given the presence of these packages, you can do it manually fairly simply.

The first method is similar to what you suggested: buffer each node by, say 20m, then dissolve these polygons and let them represent nodes. You can then count the dissolved polygons as an intersection count, and divide by area to get intersection density.

The second method is more involved but seems potentially superior. Use a density-based clustering algorithm appropriate for spatial data (such as DBSCAN using the haversine metric) to cluster nearby points within some distance threshold into a "single" intersection object. Then use them for counts, density, etc.

The main issue is, if you reduce a set of nodes into a single "intersection" object, you can no longer consistently represent the (spatially-embedded) network as a network. It is a nontrivial computational task to take a set of n nodes and m edges, remove n-1 nodes, and reconnect the m edges to the remaining node -- especially when dealing with directed edges, divided roadways, etc. It might work for metric measures (such as counts and densities) but confounds a topological graph-theoretic representation of the network.

@gboeing
Copy link
Owner

gboeing commented Apr 26, 2017

Another idea: say your city has east-west streets named A, B, C, etc and north-south streets named 1st, 2nd, 3rd, etc. If A street and 1st street are not divided roads, there will be a single node at their intersection. If B street and 2nd street are both divided roads, there will be four nodes representing their intersection. We could thus de-duplicate nodes by the street names of the edges incident to them. This again solves the geometric challenge, but not the topological one.

@gboeing
Copy link
Owner

gboeing commented Apr 27, 2017

@denadai2 see OSMnx's new clean_intersections function and this example notebook demonstration

gboeing added a commit that referenced this issue Jul 22, 2017
gboeing pushed a commit that referenced this issue Aug 24, 2020
merge latest version of gboeing osmnx master
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants