Handling One-Way Streets in Python NetworkX

Handling one-way streets in Python NetworkX requires modeling the street network as a directed graph (nx.DiGraph) where each edge explicitly encodes traversal directionality. Undirected graphs (nx.Graph) ignore directional constraints and will route vehicles against traffic, producing invalid logistics paths. To enforce real-world routing rules, you must preserve edge direction during graph construction, normalize OpenStreetMap oneway tags, assign direction-aware weights, and use algorithms that respect source → target traversal.

Why DiGraph Is Non-Negotiable

NetworkX separates topology from routing logic. The nx.DiGraph class enforces strict directional traversal, which directly maps to how road networks operate. When you call nx.dijkstra_path() or nx.astar_path() on a DiGraph, the algorithm only follows edges from u to v. If a street is one-way in the opposite direction, the algorithm treats it as non-existent for that traversal.

Using nx.Graph merges u→v and v→u into a single undirected edge. Pathfinding will freely cross one-way boundaries, violating traffic laws and breaking delivery ETA calculations. Always instantiate or convert your network to DiGraph before routing.

Normalizing OpenStreetMap oneway Tags

Raw geospatial exports rarely use consistent boolean flags. The OSM oneway key appears as True, 1, "yes", "no", or "-1" (indicating a one-way street flowing from target to source). NetworkX does not auto-parse these strings; you must normalize them into strict directional rules before routing.

The "-1" case is particularly critical for logistics pipelines. It means the edge is traversable, but only in reverse. You can handle it by:

  • Reversing the edge (u, v) → (v, u) during graph construction
  • Creating a bidirectional edge with asymmetric weights (e.g., weight=inf for the illegal direction)
  • Letting OSMnx handle it natively via network_type="drive" (recommended for standard pipelines)

For custom data ingestion, explicit normalization prevents silent routing failures. See the OpenStreetMap Wiki documentation on the oneway key for the full specification of valid tag values.

Assigning Direction-Aware Edge Weights

Directionality alone doesn’t guarantee optimal routing. Logistics engines must calibrate edge weights to reflect speed limits, congestion, vehicle class restrictions, and delivery time windows. Dijkstra and A* implementations require consistent, positive weight dictionaries. When weights vary by direction (e.g., uphill vs downhill, or truck-restricted lanes), you must assign them per-edge, not globally.

For production routing, travel time in seconds is the most reliable weight metric. Calculate it using segment length and posted speed limits, applying fallbacks for missing data. This approach directly feeds into NetworkX Shortest Path Algorithms for Logistics, where algorithm selection hinges on weight consistency and heuristic accuracy.

Production-Ready Routing Implementation

The following workflow demonstrates a complete, direction-aware routing pipeline. It normalizes oneway tags, computes travel-time weights, and safely handles disconnected nodes.

import networkx as nx
import osmnx as ox

# 1. Ingest drive network (OSMnx auto-parses oneway & returns DiGraph)
G = ox.graph_from_place("San Francisco, California, USA", network_type="drive")

# 2. Explicitly normalize oneway attributes for custom pipelines
for u, v, data in G.edges(data=True):
    val = data.get("oneway", False)
    if isinstance(val, str):
        data["oneway"] = val.lower() in ("yes", "1", "true")
    elif isinstance(val, (int, float)):
        data["oneway"] = bool(val)
    # OSMnx already handles "-1" by reversing edges during graph creation

# 3. Ensure strict directionality (defensive programming)
if not isinstance(G, nx.DiGraph):
    G = G.to_directed()

# 4. Assign direction-aware travel time weights (seconds)
for u, v, data in G.edges(data=True):
    length_m = data.get("length", 1.0)
    speed_kmh = data.get("maxspeed", 50)  # Fallback to 50 km/h
    # Convert: (km) / (km/h) = hours → * 3600 = seconds
    data["travel_time"] = (length_m / 1000) / (speed_kmh / 3600)

# 5. Resolve nearest graph nodes to coordinates
origin = ox.distance.nearest_nodes(G, -122.4194, 37.7749)
destination = ox.distance.nearest_nodes(G, -122.4084, 37.7849)

# 6. Route with direction enforcement & error handling
try:
    route_nodes = nx.dijkstra_path(G, origin, destination, weight="travel_time")
    route_time_sec = nx.path_weight(G, route_nodes, weight="travel_time")
    print(f"Route found: {len(route_nodes)} nodes, {route_time_sec/60:.1f} minutes")
except nx.NetworkXNoPath:
    print("No valid route exists respecting one-way constraints.")

Validating Routes & Handling Edge Cases

Even with a correctly structured DiGraph, routing can fail due to network topology or coordinate snapping. Always wrap pathfinding in try/except nx.NetworkXNoPath blocks. If routes consistently fail, verify:

  • Coordinate snapping: ox.distance.nearest_nodes() may snap to a one-way street flowing away from your origin. Use ox.distance.nearest_nodes(G, lon, lat, return_dist=True) to inspect proximity and fallback to a secondary node if needed.
  • Disconnected components: Urban networks sometimes contain isolated subgraphs due to data gaps. Run nx.is_strongly_connected(G) to verify bidirectional reachability, or use nx.strongly_connected_components() to isolate valid routing zones.
  • Turn restrictions: One-way streets often intersect with turn-only lanes. NetworkX doesn’t model turn restrictions natively. For high-fidelity routing, expand to edge-based graphs or integrate Python Routing Engines & Isochrone Mapping frameworks that support turn penalties and node-level transition matrices.

Key Takeaways for Production Systems

  • Always use nx.DiGraph for road networks; nx.Graph will violate traffic laws.
  • Normalize oneway strings and integers to strict booleans before routing.
  • Assign per-edge weights (travel time, cost, or logistics penalties) rather than relying on raw distance.
  • Validate route existence and handle NetworkXNoPath gracefully in production APIs.
  • For turn restrictions, multi-modal routing, or real-time traffic, layer specialized routing engines on top of NetworkX’s graph primitives.