paleolimbot

3 ms·

1. 1.▲
   by paleolimbot 1y ago

   Agreed that the polars interface is far superior to SQL! There are a few ways to do this if there's interest...polars wasn't an option because we needed Arrow extension types ( https://github.com/pola-rs/polars
2. 2.▲
   by paleolimbot 1y ago

   It's built on a separate stack but conceptually it's very similar (DataFusion shares a number of idioms with Spark and has a number of projects implementing various Spark compatibility)...I think the idea was to bring the successf
3. 3.▲
   by paleolimbot 1y ago

   Currently, lazier GeoParquet reads, a K-nearest neigbours join, Coordinate Reference System tracking, and built-in GeoPandas IO. These aren't things that DuckDB spatial can't or won't do, but they are things that DuckDB hasn&
4. 4.▲
   by paleolimbot 1y ago

   SedonaDB can decode PROJJSON and authority:code CRSes at the moment, although the underlying representation is just a string. In this case you might want something like CZBOND:999 or { "type": "EngineeringCRS", &
5. 5.▲
   by paleolimbot 1y ago

   PostGIS is great when your data is already in a Postgres table! SedonaDB and DuckDB are much faster when your data starts elsewhere (e.g., GeoParquet files).