Add junction/intersection types to nodes

[EwoutH]

Contributing guidelines

• I understand the contributing guidelines

Documentation

• My proposal is not addressed by the documentation or examples

Existing issues

• Nothing similar appears in an existing issue

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:

import osmnx as ox

# Example pseudocode for proposed feature usage
location = "Downtown, AnyCity"
network_type = 'drive'
# Proposed feature enhancement to include junction type tagging
G = ox.graph_from_place(location, network_type=network_type, tag_junctions=True)

# Simplify and consolidate intersections while preserving junction type information
G_simplified = ox.consolidate_intersections(G, tolerance=15, rebuild_graph=True, tag_junctions=True)

# Example analysis or visualization leveraging junction type information
junction_types = nx.get_node_attributes(G_simplified, 'junction_type')
# Further processing or visualization code here

Nothing is final, I would just like to open the discussion about tagging junction types.

[gboeing]

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.

[gboeing]

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.

[gboeing]

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.

[EwoutH]

Thanks for thinking about this! I will get back in more detail Monday, but I like the general approach.

[gboeing]

Resolution in #1144 with the graph simplification enhancement I mentioned in #1145 and additional node consolidation enhancement in #1155.

[EwoutH]

Thanks!