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

21–30 of 50 posts

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

#21

Post by neilfrndes »

whinvik wrote: post #18

What is the advantage over Duckdb with Spatial Extension.

While DuckDB is excellent, I've found the spatial extension still has some rough edges compared to more mature solutions like PostGIS.

1. The latitude/longitude ordering for points differs from PostGIS and most standard geospatial libraries, which creates friction due to muscle memory.

2. Anecdotal: spatial joins haven't matched PostGIS performance for similar operations, though this may vary by use case and data size.

3. The spatial extension has a backlog of long-standing GitHub issues.

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

#22

Post by ZeroCool2u »

Everyone asking why this exists when DuckDB or PostGIS or the JVM based Sedona already exists, clearly has not run into the painful experience of working on these large geospatial workloads when the legacy options are either not viable or not an option for other reasons, which happens more often than you might expect! And the CRS awareness!!! Incredible! This is such a huge source of error when you throw folks that are doing their best, but don't have a lot of experience with GIS workloads. Very expensive queries have had to be rerun with drastic changes to the results, because someone got their CRS mixed up.

I don't get to do geospatial work as much anymore, but I would have killed for this just a year ago.

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

#24

Post by throwmeaway222 »

ZeroCool2u wrote: post #22

Everyone asking why this exists when DuckDB or PostGIS or the JVM based Sedona already exists, clearly has not run into the painful experience of working on these large geospatial workloads when the legacy options are either not viable or not an option for other reasons, which happens more often than you might expect! And the CRS awareness!!! Incredible! This is such a huge source of error when you throw folks that a…

well for one, it's not crashing at some larger use-cases when duckdb does. according to the graph unless I'm mis-reading

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

#25

Post by cbzbc »

throwmeaway222 wrote: post #24
ZeroCool2u wrote: post #22

Everyone asking why this exists when DuckDB or PostGIS or the JVM based Sedona already exists, clearly has not run into the painful experience of working on these large geospatial workloads when the legacy options are either not viable or not an option for other reasons, which happens more often than you might expect! And the CRS awareness!!! Incredible! This is such a huge source of error when you throw folks that a…

well for one, it's not crashing at some larger use-cases when duckdb does. according to the graph unless I'm mis-reading

I'd like to know the details of the errors -- because it could have been as simple as running out of memory.

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

#26

Post by czbond »

paleolimbot wrote: post #19
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": "Tow…

Baller references and customization. Thank you for taking the time to craft that, I really appreciate it. Looking now because that was a main requirement of mine)

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

#27

Post by benrutter »

ZeroCool2u wrote: post #13
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.

Wait is this a sifferent.apache sedona to the spark based apache sedona GIS dataframe engine I've cone into contact with before?

Surely they're the same? Two sedona projects is one thing, but two apache sedona projects is sheer madness?

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

#28

Post by orlp »

MrPowers wrote: post #8
jrozner wrote: post #6

Whats the point of this over polars?

There is a project called GeoPolars: https://github.com/geopolars/geopolars From the README: > Update (August 2024): GeoPolars is blocked on Polars supporting Arrow extension types, which would allow GeoPolars to persist geometry type information and coordinate reference system (CRS) metadata. It's not feasible to create a geopolars. GeoDataFrame as a subclass of a polars. DataFrame (similar to how the geopandas. Geo…

I'm working on implementing extension types in Polars. Stay tuned.

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

#29

Post by ZeroCool2u »

benrutter wrote: post #27
ZeroCool2u wrote: post #13

Earlier quoted context omitted.

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.

Wait is this a sifferent.apache sedona to the spark based apache sedona GIS dataframe engine I've cone into contact with before? Surely they're the same? Two sedona projects is one thing, but two apache sedona projects is sheer madness?

Yes, this is Apache SedonaDB and the other is just Apache Sedona (Spark)
Post reply on HN