-
Notifications
You must be signed in to change notification settings - Fork 23
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
Release plans for GDAL 3.8.1 #330
Comments
Hello! GDAL has been supporting the use of spatialite functions for many many years. The PR you reference to just added spatialite to the docker container "ubuntu-small" (in may 2022), so people using that specific container can use spatialite (without having to recompile GDAL). So, normally you should be able to use the above with about any version of GDAL and at least pyogrio 0.4.0. Maybe you just wrote the SQL query like that for brevity, but to avoid misunderstandings, If you are specifically looking for a way to only read the records that intersect with a geometry (using the spatial index), pyogrio 0.7 even has a specific new feature for this:
|
Hello!
But the mentioned example works best!
My original post comes from weird behavior found when redoing:
Looks like when querying the GPKG file, some functions/aliases are missing. Not sure if this is a bug or expected behaviour. The complete list of missing functions/aliases in GPKG context is:
Full log
|
Interesting... and a bit weird. I looked a bit further into it... especially because I have a different experience for HasSpatialIndex: in my experience it is the other way around: that it only works for GPKG and doesn't for SQLite files. When I run the test you did above I get some different results on my system/environment (conda-forge based on Windows) than you did:
However, for HasSpatialIndex it is reported the same as for you: missing for GPKG. But, as I experienced before, when I run SELECT HasSpatialIndex(...), it does work for GPKG but doesn't for SQLite? So... weird things all over... My test script:
|
FWIW, this is only about the GDAL small docker images that will now contain a GDAL built with libspatialite, but we are not using those docker images to build our wheels, so that shouldn't impact the wheel build, which at this point still doesn't include libspatialite support, i.e. the libspatialite feature is not enabled in the vcpkg GDAL build. Looking at it again, it seems we could do that . @brendan-ward you commented about that in #86 (comment):
In #161 I first added Now, I don't think licensing is a problem, given that GEOS also uses LGPL, and we do already include that in the wheels. Given that vcpkg has the feature to build GDAL with libspatialite, we should probably just try that. |
Worth trying to include it since it is available. I don't recall why I flagged the license , but you're right that GEOS is the same way. |
Going to close this. Pyogrio 0.8 was released with wheels containing GDAL 3.8.5, and we have #378 about the issue of including spatialite in the wheels. |
Hey! Thanks for all the great work!
pyogrio
is super useful as companion to geopandas and GPKG The latest GDAL release -3.8.1
includes spatialite support which was requested as a result of PR: #70 (comment)As a
pyogrio
user I can't wait to start to useread_dataframe(file, sql="select ... where st_intersects(..., ...);")
which offloads computations to the underlying spatial index. Currently, to achieve this, compilation from sources is necessary which can be tricky on older systems. Precompiledpyorgio
that includes spatialite support would be neet. Any release plans?Tests look promising: #327 🙌
The text was updated successfully, but these errors were encountered: