-
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
Further PROJ/GDAL CRS vulnerability #426
Comments
Thanks Roger. The above commit converts it to an sf-native function. Does that solve the issue from you perspective? Overall I think a gradual deprecation of |
Also added this: 9cd4c0f |
Heads-up @rsbivand it seems like many things fail now with early versions of PROJ. To fix the failing examples, which I think also affect CRAN test results, I'm adding these lines before running offending examples:
is that a valid approach? |
Either that, or use only sf >= 0.9-6 (coming very soon). CRAN spotted the problem some days after Joe Cheng hit it in leaflet. sf had not conditioned on PROJ/GDAL versions in coercing CRS to crs, so fed a WKT2 string to software versions that did not handle modern WKT2 adequately. From 0.9-6, sf uses the Proj4 string of the CRS object to generate its WKT when only older GDAL/PROJ (pre-barn-raising) are present. I'd say wait for sf 0.9-6. |
Well the tests are passing now. I've just replied to an email from CRAN copying you in asking about legacy versions of PROJ etc. Impressive that the next version of sf ensures backwards compatibility, let me know if you'd like me to test. I think that the errors that recent changes in stplanr were designed to address still appear with PROJ < 6 even with the development version of sf. |
Could you please check which errors still appear, and attach check output,
etc.?
Roger Bivand
Falsensvei 32
5063 Bergen
fre. 4. sep. 2020, 09:54 skrev Robin <notifications@github.com>:
… Well the tests are passing now. I've just replied to an email from CRAN
copying you in asking about legacy versions of PROJ etc. Impressive that
the next version of sf ensures backwards compatibility, let me know if
you'd like me to test.
I think that the errors that recent changes in stplanr were designed to
address still appear with PROJ < 6 even with the development version of sf.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#426 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACNZ3BBK3SW74IJQAXVNRVLSECML5ANCNFSM4QU3QTVA>
.
|
Sure - tests on dev sf and old PROJ documented here: #428 I recall previous tests with dev sf failed on the same system so I expect the CI to fail on Ubuntu 16.04. |
Update @rsbivand here is an example of an error on dev sf with an old version of PROJ that works with newer PROJ versions:
|
That's on |
I'm seeing further trouble with constructions like
sp::proj4string(out) <- sp::proj4string(l)
in R/od-funs.R, line 397, which should probably be something likeslot(out, "proj4string") <- slot(l, "proj4string")
to be sure to transfer the WKT2 comment. It is likely that+towgs84=
will become fragile soon-ish. The problem I hit was running thetoptail_buff()
example, wheresp::identicalCRS()
failed inover()
.The text was updated successfully, but these errors were encountered: