On 12/10/20 8:56 PM, Paul Ramsey wrote:
> http://download.osgeo.org/geos/geos-3.9.0rc1.tar.bz2
So the geos-3.9.0.tar.bz2 that was there yesterday was a mistake (it's
gone now)?
> Last chance to dance. Download, build, check. I release final tomorrow.
3.9.0 is already in Debian unstable using
Yeah, I was all ready to drop 3.9.0 when the ng config issue came down and now
someone (you!) is yelling to sneak something in too. Anyways, should be all
cleaned up and sitting at rc1 now. let's be really really final soon, because
this is ridonculous.
P
> On Dec 10, 2020, at 3:14 PM, Sandro
#1045: Buffer returns unexpected geometry
+---
Reporter: Mike Taves | Owner: geos-devel@…
Type: defect | Status: new
Priority: major | Milestone: Upstream
Component: Default | Version: master
Severity:
I merged in the work I'm comfortable with, so please go ahead with yours.
And thanks for taking that on!
Dan
On Thu, Dec 10, 2020 at 5:10 PM Paul Ramsey
wrote:
> Dan, et al,
>
> I've got a noisy branch I'm thinking of merging into master.
>
> https://github.com/pramsey/geos/tree/namespace
>
On Thu, Dec 10, 2020 at 11:56:53AM -0800, Paul Ramsey wrote:
> http://download.osgeo.org/geos/geos-3.9.0rc1.tar.bz2
>
> Last chance to dance. Download, build, check. I release final tomorrow.
I see that 3.9.0 tag was already pushed to git,
could you please drop that and replace with rc1
until
On Fri, 11 Dec 2020 at 08:56, Paul Ramsey wrote:
>
> http://download.osgeo.org/geos/geos-3.9.0rc1.tar.bz2
Looks fantastic! But two complaints:
1. Consider https://git.osgeo.org/gitea/geos/geos/pulls/113 for the
final release (and cherry-pick to master), so that MSVC tests pass,
particularly
Dan, et al,
I've got a noisy branch I'm thinking of merging into master.
https://github.com/pramsey/geos/tree/namespace
https://trac.osgeo.org/geos/ticket/915
Do you want to dump your performance work in before I merge? It might not
conflict, but it's a lot of lines.
P
Previous reports show build issues on the M1 still unresolved.
Any help you can provide when you have one under your fingers, much appreciated.
P
> On Dec 10, 2020, at 1:04 PM, Andrew Hershberger
> wrote:
>
> GEOSwift looks fine with RC1 on macOS (Intel), iOS, tvOS, and Ubuntu 18.04.
> Will
GEOSwift looks fine with RC1 on macOS (Intel), iOS, tvOS, and Ubuntu 18.04.
Will get results on an M1 Mac in the next 6–12 hrs.
On Thu, Dec 10, 2020 at 1:56 PM Paul Ramsey
wrote:
> http://download.osgeo.org/geos/geos-3.9.0rc1.tar.bz2
>
> Last chance to dance. Download, build, check. I release
http://download.osgeo.org/geos/geos-3.9.0rc1.tar.bz2
Last chance to dance. Download, build, check. I release final tomorrow.
P
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel
+1 for getting rid of the compile time switch.
> -Original Message-
> From: geos-devel [mailto:geos-devel-boun...@lists.osgeo.org] On Behalf Of
> Paul Ramsey
> Sent: Thursday, December 10, 2020 12:17 PM
> To: roger.biv...@nhh.no
> Cc: GEOS Development List
> Subject: Re: [geos-devel]
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
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
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
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
#1085: RelateOp crashes on input with empty components
+---
Reporter: strk| Owner: strk
Type: defect | Status: assigned
Priority: blocker | Milestone: 3.6.4
Component: Default | Version: 3.6.3
On Thu, Dec 10, 2020 at 12:16:40PM +0100, Sandro Santilli wrote:
> On Thu, Dec 10, 2020 at 12:08:58PM +0100, Sandro Santilli wrote:
>
> > Odd, for a MULTIPOINT with empty components it seems to strip it.
> > But I cannot add the test because it looks like EMPTY is not accepted
> > in WKT:
> >
>
#1085: RelateOp crashes on input with empty components
+--
Reporter: strk| Owner: geos-devel@…
Type: defect | Status: new
Priority: major | Milestone: 3.6.4
Component: Default |Version: 3.6.3
On Thu, Dec 10, 2020 at 12:08:58PM +0100, Sandro Santilli wrote:
> Odd, for a MULTIPOINT with empty components it seems to strip it.
> But I cannot add the test because it looks like EMPTY is not accepted
> in WKT:
>
> MULTIPOINT(EMPTY,1 1,EMPTY,0 0)
> ParseException: Expected number but
On Thu, Dec 10, 2020 at 01:35:17AM +0100, Even Rouault wrote:
> On mercredi 9 décembre 2020 12:13:17 CET Sandro Santilli wrote:
> > I found out that GEOSMakeValid will remove EMPTY components from
> > collections. The PostGIS implementation of it does not do this.
> >
> > The rationale was that a
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
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
24 matches
Mail list logo
