Show HN: OpenTimes – Free travel times between U.S. Census geographies (opens in new tab)

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;

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.

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...

Also just so I’m clear, is the shading corresponding to a time the represent mean travel time for the area, or the max travel time? E.g. if you pick Walking, and a neighborhood next to Central Park in New York City, even Even though parts of Central Park are directly adjacent to that neighborhood and should be a short travel time. The entirety of Central Park is shaded with a longer travel time, Does this mean I could theoretically get to the furthest point away from the selected area in Central Park in that travel time or is that more of like a mean travel time within that area and some travel times will be shorter or longer?

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.

[0] https://www.smappen.com/

* 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.

The technical approach is also fascinating—using static Parquet files on R2 instead of a traditional database keeps costs low while maintaining accessibility via SQL and DuckDB. Offloading computation to GitHub Actions is a clever way to handle large-scale processing efficiently.

It'll be interesting to see how this evolves, especially with the potential addition of traffic-aware travel times. Great work!

Kudos!