Early warning that **sf** built with forthcoming GEOS breaks **plotly**

[rsbivand]

Forthcoming GEOS 3.9.0 introduces a new internal overlay-NG engine. The output geometries differ (in order we think) from current and previous GEOS. I'm seeing:

plotly_00check.log
testthat.Rout.fail.zip

My local attempts to debug further were stopped by not finding expect_doppelganger_built() - if you can show me how to run the offending test file completely manually - copy & paste - I can check further. Repair will be to change the tests to make them robust to the underlying GEOS engine (things like st_intersection() output order).

[cpsievert]

Thanks for the heads-up @rsbivand, I can look into it -- do you have a timetable for a CRAN release?

[rsbivand]

No, because the different CRAN platforms update external software differently. The current CRAN sf and rgeos versions expose the vulnerability. The new Overlay-NG engine in GEOS probably from 3.9.0 (no release date) is under testing, is probably much faster for larger data, but re-orders output in some cases: r-spatial/sf#1510 (comment). Edzer added a docker instance here: r-spatial/sf@fa0cf29 cloning the GEOS repo and adding the --enable-overlayng configure argument for GEOS itself.

[cpsievert]

Ah, ok, in that case it'd be great to get some help. To inspect these test failures, it'd be easiest to just change this line

https://github.com/ropensci/plotly/blob/9bc585/tests/testthat/test-ggplot-sf.R#L32

to

l <- ggplotly(p)$x

[rsbivand]

Briefly:

> l$data[[4]]$x
[1] 7.0 6.0 5.5 7.0 7.0 7.0
> l$data[[4]]$y
[1] -0.5 -0.5  0.0  0.0 -0.5 -0.5

so that the sequence starts in position 3, and duplicates ring closure in a different place. Hard to test equivalence across GEOS versions. More later.

[rsbivand]

I've asked: https://lists.osgeo.org/pipermail/geos-devel/2020-October/009756.html whether there is, or could be, a way of branching unit tests on whether Overlay-NG is active or not.

[rsbivand]

On the geos-devel list thread linked above, they suggest normalizing the objects before converting back to R objects. This would, in the case I've tested, mean changing all hard-wired output orderings, but then the normalized output should be the same irrespective of GEOS version. Is that pain less than having to branch on GEOS version?

[rsbivand]

@edzer and I feel after consideration that branching tests on the GEOS version < "3.9.0" for legacy behaviour, and >= "3.9.0" for Overlay-NG is least invasive. All alternatives involve changes to examples, tests, etc., in packages using GEOS through sf, rgeos or others.

[cpsievert]

Good to know, thanks, is there an sf or rgeos function I can use to query the version? Or do I have to resort to a system() command?

[edzer]

Yes:

sf::sf_extSoftVersion()["GEOS"] >= "3.9.0"

[rsbivand]

For rgeos: rgeos::version_GEOS() gives the whole string, rgeos::version_GEOS0() the first five characters.