Show HN: US Routing – Python library for fast local routing in the US

Thx for the heads up on optimizations available. The “Approximations” comment does not apply to the shortest path calculation, but rather to the distances and upper bound times estimations. This is the consequence of enabling routing for points that dont exist as nodes (closest node approximation).

> Although the 'routing' here is nx.shortest_path, which is just Dijkstra, so pretty slow compared to other easy to implement routing algorithms

networkx has advantages of being popular, well-documented, pure python (less hassle to maintain) with code that is easy to read and modify. but, one big downside of being pure python means that it also has fundamentally poor performance: it can't use a cpu efficiently, the way the graphs are represented also means it can't use memory, memory bandwidth or cache efficiently either.

orthogonally from switching the search algorithm, one quick way to potentially get a large speedup is try swapping out networkx for rustworkx (or any other graph library with python bindings that has native implementations of data structures and graph algorithms)

another thing to check would be to avoid storing auxiliary node/edge attributes in the graph that aren't necessary during search, so that cache and memory bandwidth can be focused on node indices and edge weights.

I went down a rabbit hole playing around with this some years ago (using Cython not rust). Relatively simple things like "store the graph in an array-oriented way (CSC/CSR sparse matrix format or similar)" and "eliminate all memory allocation and pure python code from the Dijkstra search, replace it with simple C code using indices into preallocated arrays" gets you pretty far. It is possible to get further performance increases by reviewing and tweaking the search code to avoid unnecessary branches, investigating variants of the priority queue used to maintain partial paths by path distance (i found switching the heap queue from a binary tree to a 4-ary tree gave a 30% reduction in running time), seeing if the nodes of the graph can be reindexed so that nodes with similar indices are spatially similar and more likely to be in cache (another 30% or so reduction in running time from Hilbert curve ordering). Some of this will be quite problem and data dependent and not necessarily a good tradeoff for other graphs. All up I got around a 30x speedup vs baseline networkx for dijkstra searches to compute path distances to all nodes from a few source nodes on a street network graph with 3.6m nodes & 3.8m edges (big enough not to fit in L3 cache for the CPU i was running experiments with).

What does light-weight mean in this case? Less data? Ease of installation?

"This NTAD dataset is a work of the United States government as defined in 17 U.S.C. § 101 and as such are not protected by any U.S. copyrights. This work is available for unrestricted public use."

I based my work on this, maybe the link is out, thx for testing. The dataset has already been consumed and collapsed into a smaller graph representation.

if you follow the link in the github readme, there are a few other download options for the dataset, like CSV or shapefile

Contributions are welcomee!!

By the looks of things, uv is telling you it’s creating a venv with Python 3.10.9 still. Since you didn’t specify you wanted another version, it probably defaulted to the first available system version.

What you want is `uv venv —python 3.11` to create a virtual environment with Python 3.11 without messing up your global system env. This should also install a portable version of Python 3.11 if needed (which it will be since you don’t have it).

https://docs.astral.sh/uv/pip/environments/#creating-a-virtu...

This library can use any version of Python 3.11, which you can install alongside your existing 3.10.9 without changing your global python version. I don't typically work in Windows so the codeblock below is AI generated, but follows the path I would normally take - manage installed python versions using pyenv, changing the python version only for this directory via .python_version, and then creating uv environment using that.

``` :: Step 1: Install pyenv-win (make sure Git is installed) git clone https://github.com/pyenv-win/pyenv-win.git "$env:USERPROFILE\.pyenv"

:: Step 2: Add pyenv to PATH (run or add to your profile) $env:PYENV = "$env:USERPROFILE\.pyenv\pyenv-win" $env:PATH += ";$env:PYENV\bin;$env:PYENV\shims"

:: Step 3: Restart your terminal or reload environment if needed :: (you can paste the above $env:... lines again after restart)

:: Step 4: Install Python 3.11 pyenv install 3.11.9

:: Step 5: Set the local Python version for your project folder cd C:\devel\us-routing-master\us_routing pyenv local 3.11.9

:: Step 6: Verify correct Python is selected pyenv which python # should point to 3.11.x

:: Step 7: Create uv environment using Python 3.11 uv venv .venv --python "$(pyenv which python)"

:: Step 8: Activate the environment .venv\Scripts\activate

:: Step 9: Install your package uv pip install us-routing ```

pyenv is a great way to have many versions of Python installed, whether or not your global is mapped to the latest. You don't even need to set the local .python_version.. you could just do `uv venv .venv --python=python3.11`

This is a project I did not maintain much for the past few months, but recently I migrated many other codebases to be uv managed, and I find this optimal for many reasons. Happy to receive contributions and fix the quite strict requirements I set. That would probably be the faster way.

You need to request a specific python version compatible with this project. Give `uv venv --python 3.11` a try.

https://docs.astral.sh/uv/pip/environments/

You just created a venv but didn't change the Python version.

I imagine you'd want:

uv venv --python 3.11

it can be extended arbitrary given the proper dataset. For the current default settings, road class covers everything below 3. This translates to

FREEWAY = 1 # Freeway (Multi-lane, controlled access)

PP_TH = 2 # Primary Provincial/Territorial highway

SP_TH_MA = 3 # Secondary Provincial/territorial highway/ municipal arterial

MC_USP_TH = 4 # Municipal collector/Unpaved secondary provincial/territorial highway

LS_WR = 5 # Local street/ winter road

3 was the sweetspot. The dataset can be explored here in case you want to get an intuition on detail level. https://geodata.bts.gov/datasets/usdot::north-american-roads...

Graph traversal is a classical AI problem. See Ch. 3 from AIMA: https://aima.cs.berkeley.edu/index.html

I assume you mean non-LLM.

does that account for 1% of gmaps functionality?