[HN Gopher] Show HN: OpenTimes - Free travel times between U.S. ...
___________________________________________________________________
Show HN: OpenTimes - Free travel times between U.S. Census
geographies
Hi HN! Today I'm launching OpenTimes, a free database of roughly
150 billion pre-computed, point-to-point travel times between
United States Census geographies. In addition to letting you
visualize travel isochrones on the homepage, OpenTimes also lets
you download massive amounts of travel time data for free and with
no limits. The primary goal here is to enable research and fill a
gap I noticed in the open-source spatial ecosystem. Researchers
(social scientists, economists, etc.) use large travel time
matrices to quantify things like access to healthcare, but they
often end up paying Google or Esri for the necessary data. By pre-
calculating times between commonly-used research geographies (i.e.
Census) and then making those times easily accessible via SQL, I
hope to make large-scale accessibility research cheaper and
simpler. Some technical bits that may be of interest to HN folks:
- The entire OpenTimes backend is just static Parquet files on R2.
There's no RDBMS or running service. The whole thing costs about
$10/month to host and is free to serve. - All travel times were
calculated by pre-building the inputs (OSM, OSRM networks) and then
distributing the compute over hundreds of GitHub Actions jobs. -
The query/SQL layer uses a setup I haven't seen before: a single
DuckDB database file with views that point to static Parquet files
via HTTP. Finally, the driving times are optimistic since they
don't (yet) account for traffic. This is something I hope to work
on in the near future. Enjoy!
Author : dfsnow
Score : 71 points
Date : 2025-03-17 20:40 UTC (2 hours ago)
(HTM) web link (opentimes.org)
(TXT) w3m dump (opentimes.org)
| pimlottc wrote:
| Looks cool. Please allow high max zoom levels, it's hard to see
| individual street details on mobile.
| dfsnow wrote:
| Good point, will do!
| c_moscardi wrote:
| Amazing! GitHub actions to compute a giant skim matrix is an
| incredible hack.
|
| I pretty regularly work with social science researchers who have
| a need for something like this... will keep it in mind. For a bit
| we thought of setting something like this up within the Census
| Bureau, in fact. I have some stories about routing engines from
| my time there...
| ynac wrote:
| Well done, dfsnow!
|
| * some islands seem hamstrung by the approach - see Vashon Island
| for example.
|
| * curious what other dataset you might incorporate for managing
| next level of magnitude smaller trips - e.g. getting a quarter
| mile to the store for a frozen pizza at the seventh inning
| stretch.
| bobthepanda wrote:
| Any plans on adding public transit?
| dfsnow wrote:
| In the next year or so maybe. The biggest obstacles to adding
| public transit are:
|
| - Collecting all the necessary scheduling data (e.g. GTFS
| feeds) for every transit system in the county. Not
| insurmountable since there are services that do this currently.
|
| - Finding a routing engine that can compute nation-scale travel
| time matrices quickly. Currently, the two fastest open-source
| engines I've tried (OSRM and Valhalla) don't support public
| transit for matrix calculations and the engines that do support
| public transit (R5, OpenTripPlanner, etc.) are too slow.
| p_ing wrote:
| It seems that it ignores bridges over rivers making the travel
| time wildly inaccurate.
| bongodongobob wrote:
| Not anywhere I checked.
| dfsnow wrote:
| It's just using OpenStreetMap tags for routing, so if a bridge
| is impassible by foot/bike according to OSM, then it won't be
| able to route there. See the Verrazano-Narrows Bridge in New
| York as an example.
| ctrlp wrote:
| This is great! I've been thinking about building something like
| this for ages since I started using Smappen [0] for mapping
| travel times on road trips. Super useful way to travel if you're
| on an open-ended trip with flexibility.
|
| [0] https://www.smappen.com/
| ctrlp wrote:
| Would be great to have multiple layers of times so you can plan
| out possible routes over days.
| codingmoney wrote:
| well done
| initramfs wrote:
| awesome
| simonw wrote:
| OK the way you're publishing the data with Parquet and making it
| accessible through DuckDB is _spectacular_.
|
| Your README shows R and Python examples:
| https://github.com/dfsnow/opentimes?tab=readme-ov-file#using...
|
| I got it working with the `duckdb` terminal tool like this:
| INSTALL httpfs; LOAD httpfs; ATTACH
| 'https://data.opentimes.org/databases/0.0.1.duckdb' AS opentimes;
| SELECT origin_id, destination_id, duration_sec FROM
| opentimes.public.times WHERE version = '0.0.1'
| AND mode = 'car' AND year = '2024' AND
| geography = 'tract' AND state = '17' AND
| origin_id LIKE '17031%' limit 10;
| dfsnow wrote:
| Thanks! I hadn't seen anyone do it this way before with a very
| large, partitioned dataset, but it works shockingly well as
| long as you're not trying to `SELECT *` the entire table. Props
| to the DuckDB folks.
|
| Eventually I plan to add some thin R and Python wrapper
| packages around the DuckDB calls just to make it easier for
| researchers.
| simonw wrote:
| I blogged a few more notes here:
| https://simonwillison.net/2025/Mar/17/opentimes/
| itissid wrote:
| Travel time context in general could be useful for retrieval
| before ranking in searches like Yelp or Google maps like products
| for nearby events and places. My MVP use case is to configure a
| rerank based on commute "score".
|
| For example there is just no way I'm going to commute from
| Brooklyn to Manhattan on a Monday night to eat out.
|
| I live across the river from Manhattan and what I never
| understood was why yelp and Google maps upranks restaurants
| across the river on the other island even though it is highly
| improbable I would go there.
| john-titor wrote:
| Does something like this exist for Europe?
| iscrewyou wrote:
| https://www.chronotrains.com/en
| cowsaymoo wrote:
| Only $10/mo? Where can we go to cover a month
| rvnx wrote:
| The engineering behind it is very clever. Well done!
| hatthew wrote:
| Very cool! I love the interactive map, but have a couple UX
| suggestions:
|
| I usually expect most features of a map to be zoom invariant,
| with the exception of level of detail. Having the colormap change
| is surprising, particularly that longer time buckets simply
| disappear as I zoom in. The two problems with this are that any
| time I zoom in or out I now have to double check the color key in
| case it's changed, and if I want to find a travel time for
| something far away I need to zoom in to find the destination and
| then back out to see the travel time. Perhaps you can let the
| user manually choose the colormap granularity/range, or find some
| way to have a colormap that works at all scales?
|
| Second suggestion, related, is to display the travel time next to
| the geography ID in the bottom left corner. This would mitigate
| the issues with getting a good colormap, since I can then just
| hover over a geography to get its time anywhere that the colormap
| isn't sufficient.
___________________________________________________________________
(page generated 2025-03-17 23:00 UTC)