-
Notifications
You must be signed in to change notification settings - Fork 303
Test error: Cannot open layer Parcely #1583
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
Comments
Try
|
That was also what I had in mind; I see libexpat used whenever something is XML-based (as GML is). |
Right now we build with expat but without xerxes. Looks like GML is there:
|
Am I right that this has been resolved? (I looked at https://github.com/r-universe/r-spatial/actions ) |
I'm now seeing another error. Perhaps I am doing something wrong. Are we supposed to pass special flags when building sf against a static gdal/proj?
Right now I just set an environment variable |
Another question would be (@rsbivand ) whether, in this setup, gdal was statically linked to PROJ - I guess that would be required too? The error message indicates GDAL is there, but GDAL cannot get hold of PROJ (was not linked against proj?). |
Some older OSX build notes from Simon are found here: #327 |
Not really clear why this would bite - what does it do in rgdal or terra? Are the configure scripts different? |
We would find out if they were on the |
OK part of the problem was on my end, as the So the same as what we do for Windows here: Lines 30 to 31 in e6a6a4d
Because from the mac binaries, it seems that proj/gdal were successfully statically linked, but the configure script did not copy over the datum files into the package.
It is unclear to me how this is supposed to happen. Or does the CRAN builder have some manual hack script to insert those things after the package has been built? Check logs: |
No, no CRAN hack. In rgdal towards the end of
|
For systems with installed PROJ/GDAL, |
Right, but on r-universe we want to build redistributable binary R packages identical to those from CRAN. So we need to copy the data files. |
Copying the data files would be needed on systems other than Windows and MacOS only if you build static there too. Lots of other OSGeo software uses PROJ/GDAL/GEOS, and they expect the metadata to be systemwide on Linux, etc. Is the argument only redistributability eg. for cloud settings? This may rather point us urgently to making the data files a separate package, right? |
A data package will have the challenge that you need to verify it's correctness (does the version match that of the software?); also, for GDAL the gain would be rather modest in terms of package size reduction; PROJ is moving away from packaged data distributions (access grids on CDN). The goal of a static build may be independence of everything. Do you know how do conda & Python virtual env's do this? |
Conda etc. close to random to judge from their total absence from discussions on the PROJ/GDAL/GEOS lists. For PROJ, EPSG versions matter and are not really in step with PROJ releases. I think that the only tripup recently was that proj.db table and field names changed from versions 9 to 10, so keeping the external binaries and their data synchronised did matter. |
So having a data package on CRAN with proj.db would require OSX and windows builds to use identical PROJ versions. That kicks out PROJ. |
Well, so far we haven't updated static PROJ so often. But yes, keeping the data and the package versions matched would need checking. |
I think it would be nearly impossible to orchestrate updates to gdal and proj if all we have 10 or 20 R packages that may be linked to various versions of gdal/proj, but all have to use the same shared datum files. I think it makes sense to ship compatible datum files along with each R binary package that has been statically linked to a given gdal/proj version, as we do currently. Conda is different because they also provide conda packages with dynamic libraries for gdal and proj, and the R packages are built to dynamically link to that. So it is more similar to linux, but effectively conda replaces both the CRAN binaries and the apt/yum binaries. But in practice, this creates as many new problems as it solves. |
This problem has disappeared now that we are properly including the datum files with the package 🎉 |
Uh oh!
There was an error while loading. Please reload this page.
On R-universe we have (yet another) build of GDAL. I see this check errror: https://github.com/r-universe/r-spatial/runs/1722546400?check_suite_focus=true
This could very well be my fault for how I built GDAL. Do you have any guess which driver library need to be enabled, or if some datum file is missing?
If you have a mac, you can install the binary like this to try locally
Thanks!
The text was updated successfully, but these errors were encountered: