Add validity check per method and validity API

[BuonOmo]

Summary

Now that we can handle validity with much more finesse, we can leverage that to have a per method validity check.

Details

This PR adds the ValidityCheck implementation helper which gives the API below:

• make_valid is a best effort to return a valid version of the given polygon
• invalid_reason gives nil if valid, or a string indicating invalid reason
• check_validity! raises the invalid_reason string if invalid

This module also has a CHECKED_METHODS constant which gives every methods that will be overriden after implementation to make sure they check validity before being applied.

TODO

• Complete the CHECKED_METHODS list
• Check if the ImplHelper::ValidityCheck.override_classes is not too complicated (@keithdoggett I'd love your opinion on that one!)
• Maybe add some tests
• And the ValidityCheck module to more implementations:
  • ...
• fix tests
• create documentation related to validity changes
• update history file

[keithdoggett]

@BuonOmo I was able to fix the tests locally by adding a few more methods to UNCHECKED_METHODS. Looks like the CI is still broken though

[BuonOmo]

@keithdoggett thanks! Yeah the FFI issue is still here. I'll try and find some time in the next two weeks to fix this.

FYI I just tried something given there, yet it did not work...

Some other leads:

• cannot load such file -- ffi_c (LoadError) ffi/ffi#368
• https://stackoverflow.com/questions/65000467/libffi-so-6-cannot-open-shared-object-file-in-rails
• Ruby libffi.so.7: cannot open shared object file: ffi/ffi#881 (comment)

[keithdoggett]

@BuonOmo the macos errors are due to homebrew releasing GEOS 3.10. There were some updates to the validity handling (https://libgeos.org/posts/2021-10-01-geos-3-10-released/) and this caused some of the error messages to change. We might have to handle those tests inside the Geos/FFI specific test files and base the error on GEOS version.

I can take a look at that in the #275 branch since it is more related to that.

Assuming that is handled in #275, what else needs to be done for this PR? Documentation?

[BuonOmo]

@BuonOmo the macos errors are due to homebrew releasing GEOS 3.10. There were some updates to the validity handling (libgeos.org/posts/2021-10-01-geos-3-10-released) and this caused some of the error messages to change. We might have to handle those tests inside the Geos/FFI specific test files and base the error on GEOS version.

I can take a look at that in the #275 branch since it is more related to that.

Assuming that is handled in #275, what else needs to be done for this PR? Documentation?

Yes mostly documentation, as stated in private, I think we can merge that and open new issues / PRs to have short commits and allow external contribution for the few bits that are needed

[keithdoggett]

What's the reasoning for us having to use the unsafe versions of methods in the projected features?

[BuonOmo]

If we call the safe versions, we have some issues:

• first we end up running check_validity multiple times,
• second if one wants to call for instance proj_factory.unsafe_area, it will itself call projection.area, which checks for validity.

[keithdoggett]

@BuonOmo looks like we have to define the unsafe_point_on_surface method to pass all the tests. The other failing test cases should be handled by the GEOS 3.10 update I made in the validity-handling branch.

[BuonOmo]

@keithdoggett actually, the issue is that it is called on MultiPoint, and per spec, it has no point_on_surface method (ex: http://rgeo.wikience.org/pdf/specs/06-103r4_Implementation_Specification_for_Geographic_Information_-_Simple_feature_access_-_Part_1_Common_Architecture_v1.2.1.pdf). Hence I'd rather be in favor of removing the method when used w. multipoints (it doesn't make much sense anyway, just take a random point)

EDIT: this is another harsh one, in fact postgis accepts it everywhere (#205) since we're in ruby and in ruby everything should just work i'd say we make it feature standard, explaining that choice bcause of postgis. Ok for you?

[keithdoggett]

Ahh yes, good catch. I agree that we should add it to GeometryCollection. PostGIS/GEOS compatibility is probably more important than strict OGC alignment.