Closed EwoutH closed 8 months ago
OSMnx provides comprehensive tools for street network retrieval and analysis but lacks explicit functionality to identify and classify junction types directly from OpenStreetMap (OSM) data.
Note that the settings
module has a useful_tags_node
setting you can use to specify what node attributes you want to retrieve/retain from OSM (similarly there's a useful_tags_way
setting for edge attributes). See the docs. For example, to add in "junction" attributes you can use:
import osmnx as ox
ox.settings.useful_tags_node += ["junction"]
G = ox.graph.graph_from_place("Piedmont, CA, USA", network_type="drive")
We could also consider updating the default value of this setting if there are certain attributes that are universally valuable but currently missing by default.
Although the user can configure their graph's node attributes with the settings.useful_tags_node
setting, I think @EwoutH has a good suggestion about the usefulness of including junction data by default.
I propose we update the settings.useful_tags_node
from its current ["highway", "ref"]
value to ["highway", "junction", "railway", "ref"]
instead. This would capture common "junction" information as node attributes, and OSMnx aims to model junctions as nodes after all. If the user needs other custom information added as node attributes, the useful_tags_node
setting is always available for them to configure however desired.
It also may make sense to retain the merged nodes' attributes (as a list of unique values, just like the simplify_graph
function does) in the simplification.consolidate_intersections
function (namely, in "step 5" of its source code). Currently it only retains their original osmid values as a list, plus the new node's x and y coordinates.
Finally, we may want to build on #1117 (see also #625) to flexibly relax graph simplification strictness on a list of node attributes. That would allow users to specify node attribute keys (like "highway") that, if present, denotes a node as an endpoint no matter what. Perhaps the simplify_graph
function should accept a node_attrs
list argument to this end. And perhaps if we do go this route, that function maybe should have its new endpoint_attrs
argument renamed to edge_attrs
for clarity.
This would also be useful for capturing the presence of stop signs, traffic signals, and pedestrian crossings. If we do change the simplify_graph
function as I mentioned, that would allow you to keep those kinds of nodes in a simplified graph.
Thanks for thinking about this! I will get back in more detail Monday, but I like the general approach.
Resolution in #1144 with the graph simplification enhancement I mentioned in #1145 and additional node consolidation enhancement in #1155.
Thanks!
Contributing guidelines
Documentation
Existing issues
What problem does your feature proposal solve?
In urban traffic modeling and analysis, understanding the type of junction or intersection is crucial for estimating traffic flow, capacity, and designing efficient transportation systems. Currently, OSMnx provides comprehensive tools for street network retrieval and analysis but lacks explicit functionality to identify and classify junction types directly from OpenStreetMap (OSM) data. This limitation makes it challenging for researchers and practitioners to analyze the impact of different types of intersections on traffic dynamics without manual data enrichment or external processing.
What is your proposed solution?
I propose enhancing OSMnx with functionality to automatically identify and tag junction types during graph creation from OSM data. This feature would extract and utilize OSM tags related to junctions (
junction=*
,highway=mini_roundabout
,highway=traffic_signals
,highway=stop
,highway=motorway_junction
,railway=level_crossing
,railway=crossing
,highway=crossing
) to classify nodes in the street network graph accordingly.The integration with the existing
osmnx.simplification.consolidate_intersections
tool should be considered, ensuring that the process of simplifying and consolidating intersections preserves or appropriately aggregates these junction type classifications. This could involve developing algorithms that determine the dominant junction type within a consolidated intersection based on the original node tags or implementing rules to handle complex intersections with multiple junction types.What alternatives have you considered?
As an alternative, users could manually process and enrich OSMnx graphs with junction types by querying OSM data separately and merging it with OSMnx-generated graphs. However, this approach is cumbersome and inefficient, requiring additional steps and potentially introducing inconsistencies in data handling and integration.
Another possibility involves leveraging external tools or libraries for post-processing OSMnx graphs to classify junctions, but this would not offer the seamless integration and ease of use that could be achieved by native support within OSMnx.
Additional context
API could look something like:
Nothing is final, I would just like to open the discussion about tagging junction types.