en.osm.town is one of the many independent Mastodon servers you can use to participate in the fediverse.
An independent, community of OpenStreetMap people on the Fediverse/Mastodon. Funding graciously provided by the OpenStreetMap Foundation.

Server stats:

248
active users

#duckdb

1 post1 participant0 posts today
Replied in thread

@aspensmonster if you wanna try another approach, maybe #duckdb on command line or #dbeaver-ce?

never tested the http extension, but if your data is in csv, json or parquet you could query it directly: duckdb.org/docs/stable/extensi

but you mentioned rss, the data is probably in xml. the thunderbird addon to export it to xml and after that convert it to json would help here. if files are local you can query a list of them or a directory: duckdb.org/docs/stable/data/mu

DuckDBHTTP(S) SupportBy GitHub User

howdy, #hachyderm!

over the last week or so, we've been preparing to move hachy's #DNS zones from #AWS route 53 to bunny DNS.

since this could be a pretty scary thing -- going from one geo-DNS provider to another -- we want to make sure *before* we move that records are resolving in a reasonable way across the globe.

to help us to do this, we've started a small, lightweight tool that we can deploy to a provider like bunny's magic containers to quickly get DNS resolution info from multiple geographic regions quickly. we then write this data to a backend S3 bucket, at which point we can use a tool like #duckdb to analyze the results and find records we need to tweak to improve performance. all *before* we make the change.

then, after we've flipped the switch and while DNS is propagating -- :blobfoxscared: -- we can watch in real-time as different servers begin flipping over to the new provider.

we named the tool hachyboop and it's available publicly --> github.com/hachyderm/hachyboop

please keep in mind that it's early in the booper's life, and there's a lot we can do, including cleaning up my hacky code. :blobfoxlaughsweat:

attached is an example of a quick run across 17 regions for a few minutes. the data is spread across multiple files but duckdb makes it quite easy for us to query everything like it's one table.

There are now so many "backends" for {dplyr}—duckdb with {duckplyr}, polars with {tidypolars}, various database engines with {dbplyr}, {data.table} with {dtplyr}. Is there a blog post or flow chart somewhere with pros and cons of each? Like, comparisons of memory requirements, speed, and how likely they are to "just work"?

💻 One of the tutorials at @IC2S2 2025 in Norrköping is our tutorial on analyzing and visualizing large open human mobility data in Spain using R #rstats: ic2s2-2025.org/tutorials/

It will cover #spanishoddata (ropenspain.github.io/spanishoddata/, by @EgorKotov , @robinlovelace , Eugeni Vidal Tortosa),
#flowmapper (github.com/JohMast/flowmapper by Johannes Mast), #flowmapblue (flowmapblue.github.io/flowmapb by @ilyabo), with under the hood data crunching using @duckdb #DuckDB .