ject: Re: [geos-devel] beta2 still needs --enable-overlayng
>
> 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 conveni
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 u
This is done. There will be an rc1 shortly.
P
> On Dec 10, 2020, at 11:12 AM, Roger Bivand 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 interve
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
o
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
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
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 wor
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
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
