Skip to content
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 version number woes #71

Closed
rsbivand opened this issue Oct 11, 2020 · 2 comments
Closed

GEOS version number woes #71

rsbivand opened this issue Oct 11, 2020 · 2 comments

Comments

@rsbivand
Copy link

rsbivand commented Oct 11, 2020

I'm trying to run sf and rgeos revdep checks with forthcoming GEOS 3.9.0, which presents itself as "3.9.0dev". This fails in old_sf_geos():

  1. Error: works with self-intersections: sf (@test-fix_geo_problems.R#94)
  2. Error: works with other problems: sf (@test-fix_geo_problems.R#106)

These fork on GEOS < 3.8.0 for good reason, but do not try to strip trailing string extensions to the declared version number. This only matters if you care about protecting yourselves from the radical changes coming in GEOS 3.9.0. Your code presupposes that the version number is normalised, which it will be when 3.9.0 is released, but then it will be too late to modify code ahead of time. The rgeos tests earlier in the same file all pass, so I think the irritant is just expecting the sf GEOS version string to be normalised.

@ateucher
Copy link
Collaborator

Thanks @rsbivand, we'll look at this and tidy up that version checking.

ateucher added a commit that referenced this issue Oct 14, 2020
@ateucher
Copy link
Collaborator

@rsbivand this should be fixed now, the non-numeric version components are now converted to numeric before the comparison to v 3.8.0. Thanks for running the revdep checks and catching this!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants