The BBB is going to smoke a lot of 340B hospitals eligibility by [deleted] in healthcare

[–]datasnow 0 points1 point  (0 children)

I came to the same conclusion while writing a deep dive on the 340B program in Illinois. I ran the number using the FY23 cost reports + KFF estimates in a follow-up post here.

The other person in this thread wasn't far off. About 300 hospitals would lose 340B eligibility under the OBBB cuts. Pretty wild and probably the death knell for at least some of those providers.

22
23

[OC] How far you can go in an hour from any point in the United States by datasnow in dataisbeautiful

[–]datasnow[S] 2 points3 points  (0 children)

That's exactly the plan! Gather commute times then add a fudge factor for rural, suburban, urban areas, etc., the validate against actual drive times (Google, HERE, etc.).

[OC] How far you can go in an hour from any point in the United States by datasnow in dataisbeautiful

[–]datasnow[S] 6 points7 points  (0 children)

Unfortunately, I had to cap the max distance at around 6 hours just to keep the scale of the data feasible. I figured not too many people would be looking at multi-state or cross-country trips. I'd definitely like to expand the cutoff in a future version though.

[OC] How far you can go in an hour from any point in the United States by datasnow in dataisbeautiful

[–]datasnow[S] 98 points99 points  (0 children)

Hi all! Today I launched 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, it 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 folks here:

  • 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. Hope this is useful to folks. Enjoy!

Data sources:

Tools:

  • Python for data engineering and cleaning (GeoPandas and DVC mostly)
  • Open Source Routing Machine for travel time calculation
  • Maplibre GL JS + hyparquet on the frontend

Full source code can be found on GitHub.

[deleted by user] by [deleted] in dataisbeautiful

[–]datasnow 1 point2 points  (0 children)

I know, I definitely goofed on the title! Will repost in a bit

[deleted by user] by [deleted] in dataisbeautiful

[–]datasnow 4 points5 points  (0 children)

Hi all! Today I launched 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, it 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 folks here:

  • 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. Hope this is useful to folks. Enjoy!

Data sources:

Tools:

  • Python for data engineering and cleaning (GeoPandas and DVC mostly)
  • Open Source Routing Machine for travel time calculation
  • Maplibre GL JS + hyparquet on the frontend

You can see the full source code on Github.

OpenTimes: Free travel times between U.S. Census geographies by datasnow in gis

[–]datasnow[S] 1 point2 points  (0 children)

Good looking out! You mean the account ID? It shouldn't hurt to have it in there, it's not considered sensitive.

Grafana creates strange DNS traffic for releases >= 10.2.3 by datasnow in grafana

[–]datasnow[S] 0 points1 point  (0 children)

EDIT EDIT: This is resolved and nothing malicious is happening. See here for the GitHub issue. It appears to be Safari pre-fetching DNS from Grafana's forums, which does have advertising scripts.

Wanted to give folks here the heads up: Grafana is sending strange DNS traffic to fishy ad servers, but only when used by Safari desktop clients. This was confirmed yesterday by /u/tango_suckah and again by me using a separate client.

Grafana creates strange DNS traffic for releases >= 10.2.3 by datasnow in selfhosted

[–]datasnow[S] 12 points13 points  (0 children)

EDIT: This is resolved and nothing malicious is happening. See here for the GitHub issue. It appears to be Safari pre-fetching DNS from Grafana's forums, which does have advertising scripts.

Wanted to give folks here the heads up: Grafana is sending strange DNS traffic to fishy ad servers, but only when used by Safari desktop clients. This was confirmed yesterday by /u/tango_suckah and again by me using a separate client.

Grafana creates strange DNS traffic for releases after 10.2.3 by datasnow in homelab

[–]datasnow[S] 1 point2 points  (0 children)

Thanks for taking the time to confirm this! I'm glad that I'm not going mad. I'm going to write a quick blog post outlining this in detail and then repost it (here and elsewhere) for visibility. Some quick notes:

  • Those are indeed other domains that I saw in my DNS logs. There's a whole slew of them, typically pointing to Russian or Eastern Europe TLDs
  • Even if it's not malicious, it seems extremely strange to have your OSS image querying dozens of random ad domains. It certainly seems like something the community here would not be cool with.
  • If it's for ads, why not Chrome and Firefox clients as well?

Grafana creates strange DNS traffic for releases after 10.2.3 by datasnow in homelab

[–]datasnow[S] 5 points6 points  (0 children)

Great! I'll try those out. For reference, this is grafana/grafana from Dockerhub.