Add support for sf

[tiernanmartin]

Please consider expanding this package to include simple feature spatial data, as implemented by the sf package.

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/42049987-add-support-for-sf?utm_campaign=plugin&utm_content=tracker%2F6407602&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F6407602&utm_medium=issues&utm_source=github).

[eblondel]

Indeed it would be more than interesting and useful to support OGC simple feature specification using sf package. To investigate.. Thanks for your suggestion

[jpearson0525]

I would like to add my voice to this request for new feature. With the announcement that rgdal, rgeos, etc. will be retired the end of 2023, being able to service and clean up sf structures is really important.

[eblondel]

well noted. I don't exclude that we have to move to sf directly that provides st_make_valid. Unit tests have to performed to make sure this is robust, but so far what I could see it is.

[eblondel]

For backward compatibility the same methods (based on sp objects) have been kept in 0.3; but the main strategy to fix geometries is now delegated to sf::st_make_valid as it is the most robust solution. Other native methods were adapted to remove the dependencies with rgeos and maptools (going to be archived in Oct 2023), and might not behave exactly in the same way. The best is to do to progressively use sf but cautiously with setting sf::sf_use_s2(FALSE) to make sure the ISO/OGC geometry model is still used in the background (which is not anymore the default setting in sf. See https://github.com/eblondel/cleangeo#note-on-cleangeo-archiving-process-after-version-03-needsprerequisites-to-move-to-sf