Overnight checks on R packages show no new problems - package maintainers
were warned of failing tests as soon as OverlayNG was available for
testing.
Roger
On Thu, 10 Dec 2020, Roger Bivand wrote:
On Thu, 10 Dec 2020, Paul Ramsey wrote:
This is done. There will be an rc1 shortly.
Good, thanks. In a day or so I'll run the reverse dependency checks for R
packages interfacing GEOS (so across packages using packages interfacing
GEOS) Not all of the 900+ R packages in the spatial cluster use GEOS
directly, but many do indirectly, and have been very trustful in expecting
output to equal canned results. I warned a number in late October following a
first set of reverse dependency checks to comment out those tests (e.g. the R
plotly interface as one), so I'll try to re-check development versions if I
can locate them.
Roger
P
On Dec 10, 2020, at 11:12 AM, Roger Bivand <roger.biv...@nhh.no> wrote:
Again, from the point of view of communities like R, this would simplify
things a lot. We could then say that unless the questioner (or the person
the questioner is asking for) has intervened very actively in the source
install, >= 3.9.0 is OverlayNG, < 3.9.0 is legacy. Then the vast majority
of reproduction issues could be accounted for by reference to the version
number.
Roger
On Thu, 10 Dec 2020, Paul Ramsey wrote:
I can make it more deterministic by just removing the compile-time
option altogether. That way, you build 3.9, you get NG, no question
about it. I don't see any purpose in the compile-time switch anymore, it
was convenient during development, but now that we've done all teh
changes in regresion etc, both in GEOS and in PostGIS and so on (BTW,
don't forget to aggressively add normalize to your tests) the utility of
the compile-time switch is much lower, and we can just leave the #define
in place and manually flip it if, for some reason, we want to test old
behaviour.
Thoughts?
P
On Dec 10, 2020, at 8:46 AM, Roger Bivand <roger.biv...@nhh.no> wrote:
Thanks for responding. The motivation is that users of R (and others)
packages, using R packages interfacing GEOS will see changes in output
geometries. We can agree that the new engine is preferable, but when
their unit tests fail, they need to know why. They cannot run make
check, and in the case of most they will not have a dll or dylib
either, as the CRAN package binaries for Windows and MacOS are built
static. The lack of a convienient and deterministic route to knowing
that the reason for the different result is that GEOS is on OverlayNG
is a problem, because we cannot give easy self-help (run sf or rgeos
function x to tell you if OverlayNG is operating). All we can do is
assume for all cases that 3.9.0 is OverlayNG.
Roger
On Thu, 10 Dec 2020, Paul Ramsey wrote:
I am loath to add a live run-time API end point to check for a
"feature" that is actually the core engine. It's not like we're ever
going to allow people to swap engines. The old engine is going to
eventually be ripped out. The way you know you have NG is that you can
run "make check" and it works, because if you run "make check" with
the old engine, regression is going to fail. I can ensure there is
configure-time output on the status, but that's really about as far as
I'm willing to go.
P
On Dec 10, 2020, at 12:56 AM, Roger Bivand <roger.biv...@nhh.no>
wrote:
Even with --enable-overlayng, the ring orders are different from
those generated by OverlayNG in late October. At that stage we could
differentiate by typical ring order patterns, now something else has
changed and we cannot see whether OverlayNG is operative or not. Lots
of tests in R packages built against GEOS have relied on operations
returning ring-order identical polygons (or coord-order identical
line segments) compared with stored expected values.
Please clarify urgently: OverlayNG is not mentioned in NEWS, nor does
it appear as the last line in ./configure output; all I can see is
--disable-overlayng as a configure option. How can we test for the
presence of OverlayNG in the runtime? Recall that any user compiling
from source or any packager may use the configure argument.
Please do not simply rely on the version number, it is sufficiently
robust.
Roger
On Thu, 10 Dec 2020, Roger Bivand wrote:
Hi,
Please confirm that the 3.9.0 release will as advertised enable
OverlayNG by default. As lately as beta2 configure still seemed to
need --enable-overlayng. Ad-hoc tests from late October to detect
ring order fail without --enable-overlayng. I repeat that it is
necessary to provide a clear way to interrogate the runtime to find
out whether it supports OverlayNG.
Next question - why no RC, is it fair to just go from beta to
release?
Best wishes,
Roger
--
Roger Bivand
Department of Economics, Norwegian School of Economics,
Helleveien 30, N-5045 Bergen, Norway.
voice: +47 55 95 93 55; e-mail: roger.biv...@nhh.no
https://orcid.org/0000-0003-2392-6140
https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en
_______________________________________________
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel
--
Roger Bivand
Department of Economics, Norwegian School of Economics,
Helleveien 30, N-5045 Bergen, Norway.
voice: +47 55 95 93 55; e-mail: roger.biv...@nhh.no
https://orcid.org/0000-0003-2392-6140
https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en
--
Roger Bivand
Department of Economics, Norwegian School of Economics,
Helleveien 30, N-5045 Bergen, Norway.
voice: +47 55 95 93 55; e-mail: roger.biv...@nhh.no
https://orcid.org/0000-0003-2392-6140
https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en
--
Roger Bivand
Department of Economics, Norwegian School of Economics,
Helleveien 30, N-5045 Bergen, Norway.
voice: +47 55 95 93 55; e-mail: roger.biv...@nhh.no
https://orcid.org/0000-0003-2392-6140
https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en
_______________________________________________
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel
