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.

▲

throwmeaway222 6 hours ago | parent [-]

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

▲

cbzbc 6 hours ago | parent [-]

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

▲

MrPowers 3 hours ago | parent | next [-]

You can generate the dataset with the instructions in this readme: https://github.com/apache/sedona-spatialbench/tree/main

Here are the queries: https://github.com/apache/sedona-spatialbench/blob/main/prin...

They should be fairly easy to replicate!

▲

cyanydeez 2 hours ago | parent | prev | next [-]

OOM are still something a DB can "avoid" so it's not like that class of bugs is some special issue that nullifies thing.

▲

cinntaile 3 hours ago | parent | prev [-]

Crashing when running out of memory is not acceptable software behavior in my opinion.

	▲	cbzbc 2 hours ago \| parent [-]
		Right, but all it says is that an error was thrown.