[geos-devel] beta2 still needs --enable-overlayng

[Roger Bivand]

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.Bivand at 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.Bivand at nhh.no
>> https://orcid.org/0000-0003-2392-6140
>> https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en
>> _______________________________________________
>> geos-devel mailing list
>> geos-devel at 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.Bivand at nhh.no
https://orcid.org/0000-0003-2392-6140
https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en