Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SedonaDB: A new geospatial DataFrame library written in Rust

sedona.apache.org

Post reply on HN
Print view View original

11–20 of 50 posts

Re: SedonaDB: A new geospatial DataFrame library written in Rust

#11

Post by paleolimbot »

WD-42 wrote: post #10

I’ve been out of the geo loop for a while. I’m struggling to understand why I’d use this over postgis. There used to be the argument that installing extensions was painful, but now that docker exists pulling the postgis image is just as easy as normal Postgres. And RDS has supported it for a while. What am I missing? The api even looks the same.

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

Re: SedonaDB: A new geospatial DataFrame library written in Rust

#12

Post by MrPowers »

paleolimbot wrote: post #11
WD-42 wrote: post #10

I’ve been out of the geo loop for a while. I’m struggling to understand why I’d use this over postgis. There used to be the argument that installing extensions was painful, but now that docker exists pulling the postgis image is just as easy as normal Postgres. And RDS has supported it for a while. What am I missing? The api even looks the same.

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

The "DuckDB is probably the most important geospatial software of the last decade" post has a nice related discussion: https://news.ycombinator.com/item?id=43881468

Re: SedonaDB: A new geospatial DataFrame library written in Rust

#13

Post by ZeroCool2u »

drewda wrote: post #2

Interesting, but why share the Sedona name? I thought Apache Sedona is implemented in Java/Scala for distributed runtimes like Spark and Flink. Wouldn't Rust tooling for interactive use be built atop a completely different stack?

Apache Sedona, not so well loved in the GIS space in my experience, so I don't think it's a huge issue even if it is a bit confusing.

Re: SedonaDB: A new geospatial DataFrame library written in Rust

#14

Post by mattforrest »

larodi wrote: post #9

Somehow I dont see this applicable for 90% of all current spatial needs, where PostGIS does just right, and same IMHO goes for DuckDB. There perhaps exists 10% of business where data is so immense you want to hit it with Rust & whatnot, but all others do just fine im Postgre. My bet is most of actually useful spatial ST_ functions are not implemented in this one, as they are not in the DuckDB offering.

I wrote a book on PostGIS and used it for years and these single node analytical tools make sense when PostGIS performance starts to break down. For many tasks PostGIS works great, but again you are limited by the fact that your tables have to live in the DB and can only scale as much as the computing resources you have allocated.

In terms of number of functions PostGIS is still the leader, but for analytical functions (spatial relationships, distances, etc) having those in place in these systems is important. DuckDB started this but this has a spatial focused engine. You can use the two together, PostGIS for transactional processing and queries, and then SedonaDB for processing and data prep.

A combination of tools makes a lot of sense here especially as the data starts to grow.

Re: SedonaDB: A new geospatial DataFrame library written in Rust

#16

Post by th0ma5 »

mattforrest wrote: post #14
larodi wrote: post #9

Somehow I dont see this applicable for 90% of all current spatial needs, where PostGIS does just right, and same IMHO goes for DuckDB. There perhaps exists 10% of business where data is so immense you want to hit it with Rust & whatnot, but all others do just fine im Postgre. My bet is most of actually useful spatial ST_ functions are not implemented in this one, as they are not in the DuckDB offering.

I wrote a book on PostGIS and used it for years and these single node analytical tools make sense when PostGIS performance starts to break down. For many tasks PostGIS works great, but again you are limited by the fact that your tables have to live in the DB and can only scale as much as the computing resources you have allocated. In terms of number of functions PostGIS is still the leader, but for analytical functio…

I think this is a great perspective in my professional experience it was very common to be using multiple tools. ESRI for some things, GDAL for others, and then some hacks here and there like most complex analytical systems. Some of it vendor shenanigans but some of it is specific features.

Re: SedonaDB: A new geospatial DataFrame library written in Rust

#17

Post by WD-42 »

paleolimbot wrote: post #11
WD-42 wrote: post #10

I’ve been out of the geo loop for a while. I’m struggling to understand why I’d use this over postgis. There used to be the argument that installing extensions was painful, but now that docker exists pulling the postgis image is just as easy as normal Postgres. And RDS has supported it for a while. What am I missing? The api even looks the same.

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

Oh I see. So if you have some kind of a pipeline in which you don’t need or want to load the data into a DB first. That makes total sense, thanks!

Re: SedonaDB: A new geospatial DataFrame library written in Rust

#19

Post by paleolimbot »

czbond wrote: post #15

Question: Does SedonaDB support custom / alternative coordinate systems? For example, if i wanted to define a 4d region called (fish, towel, mouse, alien) and there were floats for each of fish/towel/mouse/alien?

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", "name": "Fish, Towel, Mouse", "datum": {"name": "Wet Kitty + Mouse In Peril"}, "coordinate_system": { "subtype": "Cartesian", "axis": [ {"name": "Fish", "abbreviation": "F", "direction": "east"}, {"name": "Towel", "abbreviation": "T", "direction": "north"}, {"name": "Mouse", "abbreviation": "M", "direction": "up"}, ] } }

(Subject to the limitations of PROJJSON, such as a 4D CRS having a temporal axis and a limited set of acceptable "direction" values)

Re: SedonaDB: A new geospatial DataFrame library written in Rust

#20

Post by paleolimbot »

whinvik wrote: post #18

What is the advantage over Duckdb with Spatial Extension.

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't prioritized over the last year that are essential to a lot of spatial pipelines.
Post reply on HN