[geos-devel] 3.9.0rc1 [was: beta2 still needs --enable-overlayng]

Fri Dec 11 01:48:38 PST 2020

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.Bivand at 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.Bivand at 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.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
>>>> 
>>>> 
>>>
>>>  --
>>>  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
>> 
>> 
>
>

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