-
Notifications
You must be signed in to change notification settings - Fork 5
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
GEOS-devel issues with OverlayNG #9
Comments
With:
siland and sabre pass, so it looks like a GDAL issue, perhaps? @edzer, will we be able to find out what happens before 3.2.0 is released? |
@rsbivand Thank you for letting me know about the issue. I am now working on creating a testing docker image. Is is possible that the package data (sf and raster objects) need to be updated (due to PROJ6+ changes)? |
Very curious, both now pass for sf 0.9-6 and GDAL 3.2.0 RC1:
As of now, the problem comes from running with the development version of sf. Installing sf from github seems to lead to failures in sabre and siland, but I'm re-checking. |
Could you please elaborate the question? |
Running revdep checks on 900+ packages with the nightly build of GEOS, GDAL 3.2.0 RC1, PROJ 7.2.0 RC1, and sf devel, I noticed failures in siland and sabre that were not there before, in sabre,
In siland,
The failures are with |
Thanks; I will try to reproduce this, am now rebuilding the overlayNG docker image with Martin's / strk's recent updates. |
Same errors with GEOS 3.8.1, GDAL 3.2.0 RC1, PROJ 7.2.0 RC1 and sf from github master, and with GEOS 3.9.0 devel without |
So GDAL RC is the smoking gun? Will build that against overlayNG. |
No, the failures are only present with sf > 0.9-6, irrespective of GDAL 3.1.4 or 3.2.0 RC1, and GEOS 3.8.1, 3.9.0 with and without OverlayNG. I only tried the GEOS variants with GDAL 3.2.0 RC1. I don't see in sf/src/wkb.cpp where any GDAL code is involved, and I can't see how the GDAL error handler is being triggered. |
I think @Nowosad found the problem - the extracts above are:
and r-spatial/sf@b8e4af4 is recent and changes how CRS are handled on export to GEOS, I think. And:
Does the change take account of NA CRS? The |
the trouble in both cases were old-style |
shows
So:
work. As does:
@edzer could you tell the siland maintainer? |
fix now in sf master. |
With GEOS devel version installed with
--enable-overlayng
, I see a failure insf_intersection()
. Here is the log and a zipfile of an rda file with objectssabre_x
andsabre_y
. Could you please check with released GEOS, then build sf and GDAL against GEOS built with--enable-overlayng
, say from a recent nightly bz-ball, and report back? See also r-spatial/sf#794.sabre_00check.log
GEOS_dev_issue.zip
Note that I'm also using GDAL 3.2.0 RC1, so the OGR: Corrupt data may be from GDAL rather than GEOS. I see a very similar error in the 'siland* package (not on github), logfile here:
siland_00check.log. If you get test containers up, debugging that error may help pin down the problem. If it is GDAL, feedback before 3.2.0 is released would help!
The text was updated successfully, but these errors were encountered: