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

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).

@rsbivand

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

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.

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

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.

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.

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?

@edzer

@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.

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?

Yes:

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

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

Closes plotly#1862. Rely on visual test of geom_sf(), making addition…

Navigation Menu

Early warning that sf built with forthcoming GEOS breaks plotly #1862

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Activity

cpsievert commented on Oct 15, 2020

rsbivand commented on Oct 15, 2020

cpsievert commented on Oct 15, 2020

rsbivand commented on Oct 15, 2020

rsbivand commented on Oct 15, 2020

rsbivand commented on Oct 15, 2020

rsbivand commented on Oct 16, 2020

cpsievert commented on Oct 16, 2020

edzer commented on Oct 17, 2020

rsbivand commented on Oct 17, 2020

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Early warning that sf built with forthcoming GEOS breaks plotly #1862