-
Notifications
You must be signed in to change notification settings - Fork 66
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Spatial extension support #141
Comments
Yes, we would like to see spatial / GIS support, it's just a matter of time and priorities. Determining how it interacts with postgis will certainly need to be part of the design. |
Thanks, will wait. |
+1 for PostGIS support! |
Does it support spatial extension yet? |
I think it won't work like your example. The main difficulty to implement is postgis—duckdb function mapping. In the PG should be used normal Postgis functions or duckdb functions from the schema duckdb. Postgis geometry is stored in the ewkb format, duckdb stores wkb - without srid and BBBox information, than could add additional difficulty. A lot of things to do .... |
PostGIS doesn't store EWKB internally, and DuckDB doesn't store WKB internally either. Both use their own internal format and while they are not identical, the DuckDB format is very much inspired by PostGIS (both store BBOX:es). The major difference is that DuckDB does not store the SRID in the geometry value itself (and doesn't really have the concept of integer SRIDs in general). I imagine the easiest solution is to just cast/convert to and from WKB when transferring geometries between DuckDB/PostGIS as ISO WKB basically models the common subset of spatial type support between the two systems. |
Do you plan to implement DuckDB spatial extension support, mainly ST_Read?
Will it be PostGIS types support?
The text was updated successfully, but these errors were encountered: