of course).
On Mon, Apr 14, 2025 at 10:12 AM Martin Davis wrote:
> Also, the input values have not been rounded to the requested precision.
> In general this should be done to use the overlay precision ops correctly.
> (The data will be rounded internally, but the results may not ma
. (One gap in the current API
is that the spatial predicates do not support a precision value. I'm
hoping to provide that at some point).
On Mon, Apr 14, 2025 at 10:04 AM Martin Davis wrote:
> I suspect that the anomalies you're seeing are because the precision grid
> size
I suspect that the anomalies you're seeing are because the precision grid
size is so small. A precision of 1e-14 combined with input values which
are on the order of 1e2 means that you are asking for 16 digits of decimal
precision, which is at or over the precision that can be represented using
do
For more context, I was cleaning up the remnants of the old overlay
engine. It had already been substantially removed in
https://github.com/libgeos/geos/pull/788. There were a few bits left,
which were used internally only by the buffer algorithm. It seems pretty
unlikely that any external code
Given the desire to avoid changes to ABI for micro versions, it sounds like
the path to removing pointer aliases is:
- remove aliases in src in main
- do not backport alias removal to previous versions (this may create some
backporting pain, but since there are relatively few uses of alias in src
ed if others want to
> take that on. I would not be in favor of backporting this type of change,
> which would break the API in a minor release while offering no benefit to
> users.
>
> Dan
>
> On Wed, Jan 8, 2025 at 7:16 PM Martin Davis wrote:
>
>> The GEOS codebase has s
The GEOS codebase has several typedefs called GeometryPtr and GeomPtr.
They are aliases for a mixture of Geometry * and std::unique_Ptr.
I'm thinking it's a good thing to purge them from the codebase in favour of
explicit type signatures, because:
- it's highly confusing that they can be aliases f
n Wed, Nov 27, 2024 at 9:32 AM arno wrote:
> Thanks a lot. I was not aware of ST_ClipByBox2D, but it seems to be what I
> need.
>
> On Tue, Nov 26, 2024 at 07:56:26AM -0800, Martin Davis wrote:
> > One reason RectangleIntersection is not enabled in the Intersection code
> >
One reason RectangleIntersection is not enabled in the Intersection code
path is that it has different semantics than the OverlayNG algorithm. This
might be undesirable or confusing in some use cases.
It is exposed by GEOSClipByRect. And this is used by PostGIS (at least in
some circumstances).
We're in the process of porting RelateNG [1] to GEOS [2]. It offers
benefits of performance, robustness, and increased functionality (e.g.
handling GeometryCollections).
RelateNG does have one slight change in semantics. It treats a Zero-Length
Line to be topologically equal to a Point:
equalsT
Add to the website?
On Tue, Jun 4, 2024 at 9:05 AM Daniel Baston wrote:
> Thanks for weighing in on this. I've gone ahead and uploaded 3.12.1 to
> Zenodo. The concept DOI is https://doi.org/10.5281/zenodo.11396894
>
> If anyone would like to see changes on the entry itself, just let me know.
>
>
Sounds fine to me.
On Thu, May 30, 2024 at 8:40 AM Daniel Baston wrote:
> Hello,
>
> Would there be any objection to me uploading the most recent release of
> GEOS to zenodo.org? Uploading a release generates a digital object
> identifier (DOI) that can be used to cite a specific release of GEOS
Discussion here:
https://github.com/libgeos/geos/issues/968#issuecomment-2041134101
This could also be raised as a separate issue.
On Mon, Mar 25, 2024 at 2:07 PM Sandro Santilli wrote:
> I'm struggling with a robustness bug in PostGIS topology [1] which
> is making me question the relate compu
+1
On Mon, Nov 6, 2023 at 11:48 AM Regina Obe via geos-devel <
geos-devel@lists.osgeo.org> wrote:
> According to our chart here:
>
> https://libgeos.org/usage/download/
>
> We should have EOL'd GEOS 3.8 last month.
>
> Looks like we have only 2 changes for 3.8.4
>
> https://github.com/libgeos/geo
https://github.com/libgeos/geos/pull/937 switches to using DoubleDouble
computation for line intersection. This improves the accuracy of
calculating line intersection points.
This fixes some egregious bugs in spatial predicate evaluation (e.g.
https://github.com/libgeos/geos/issues/933 and
https:
+1
On Sun, Jun 25, 2023 at 4:45 PM Paul Ramsey
wrote:
> Does anyone object to a 3.12.0 release on Monday/Tuesday?
>
> P.
> ___
> geos-devel mailing list
> geos-devel@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/geos-devel
>
__
The definition of a valid Simple Polygonal Coverage is presented here:
http://lin-ear-th-inking.blogspot.com/2022/08/validating-polygonal-coverages-in-jts.html
It's in the JTS Javadoc here:
https://github.com/locationtech/jts/blob/master/modules/core/src/main/java/org/locationtech/jts/coverage/C
On Tue, Apr 18, 2023 at 5:24 PM Daniel Baston wrote:
> but performs better than the old algorithm if the inputs are pre-sorted
> (as they are in the old algorithm). Maybe the same sorting should be added
> to the NG version.
>
The first step in the union algorithm is to identify segments which
On Tue, Apr 18, 2023 at 5:24 PM Daniel Baston wrote:
> I noticed that the OverlayNG coverage union returns an empty polygon if
> the inputs do not form a coverage, whereas the older algorithm produces an
> error. I think it would be a good idea to apply an area post-check to the
> NG version so t
geos/coverage/CoverageUnion in fact delegates to
geos/operation/overlayng/CoverageUnion. It's there to provide an API which
is the same as the other coverage operations.
overlayng/CoverageUnion seems to be quite a bit faster than
geos/operation/union/CoverageUnion, by my testing. So it has my vo
I commented on the ticket. It seems fine to preserve the type of the
input.
This might just be an artifact of using OverlayNG under the covers.
On Thu, Mar 9, 2023 at 12:18 PM Paul Ramsey
wrote:
> Anyone have opinions on this one?
> https://github.com/libgeos/geos/issues/662
>
> On the one han
Over the 20 year lifetime of GEOS there have been at least 6 developers
involved at a deep algorithmic level (fixing bugs and design issues and
contributing new and improved algorithms). And now that GEOS is so mature
and widely used, I'd say the bar is higher.
Anyway, the key point is: let's see
As others have said on this thread, adding curve support to GEOS is likely
to be a big effort.
My opinion is that to consider an extension of this magnitude, there needs
to be evidence that this initiative is feasible and sustainable over the
long term (at least 10 years). A good way to demonstrat
Validity is only tested in the XY dimensions. So it's actually more
appropriate that only the XY value is reported.
On Fri, Oct 21, 2022 at 7:35 AM Regina Obe wrote:
> Hi all,
>
> PostGIS geos310 regression test, detailed here:
>
> https://trac.osgeo.org/postgis/ticket/5260
>
> Started failing
An interesting idea for sure.
Do you need only the area of the intersection? If so, perhaps the
"area-only overlay" idea of William Franklin [1] would provide an even
faster/simpler implementation?
I have a prototype implementation of this in JTS. One advantage might be
that it will work for an
On Wed, Oct 5, 2022 at 7:56 AM Howard Butler wrote:
> In PDAL's (albeit unusual) usage, we pass through millions of points to do
> things like point-in-poly. Changing/copying data to fit GEOS' data
> arrangement starts to get really expensive, and for PDAL, we ended up doing
> our own PiP impleme
+1.
On Mon, Sep 12, 2022 at 11:34 AM Regina Obe wrote:
> Here is my formal request to vote on:
>
> https://libgeos.org/development/rfcs/rfc11/
>
> To accompany that change we will
>
> 1) Put a link on https://libgeos.org/usage/download/ to that policy.
> 2) Put in a Final Release Date column on
On Wed, Sep 14, 2022 at 9:35 AM Sandro Santilli wrote:
> thus triggering 4 different minor
> releases in that period (what prevents that?).
>
Our development resource bandwidth, and also downstream pipeline size.
I think we should have a policy of one minor release per year (if needed)
And (tr
On Wed, Sep 7, 2022 at 5:30 PM Daniel Baston wrote:
> But not sure how much extra overhead or difficulty that would cause for
>> other projects consuming such a new type.
>>
>
> It would be the same difficulty/overhead as creating a GeometryCollection
> instead of passing around an array of geome
>
> You read my mind. I'm fine with an additional type in PostGIS.
>
> Along the lines with what Dan Baston said, the idea of having a special
> coverage type that multiple operations can be applied to is very appealing
> to me.
>
> But not sure how much extra overhead or difficulty that would cau
On Wed, Sep 7, 2022 at 3:18 PM Sandro Santilli wrote:
> On Tue, Sep 06, 2022 at 02:37:37PM -0700, Martin Davis wrote:
> > I've started to build out operations on Polygonal Coverages in JTS ([1],
> > [2]).
>
> [...]
>
> > A key question is how to expose the
I probably should have started this discussion as a GitHub issue (better
formatting, linking, tracking etc). I will try and move this content there
soon.
On Tue, Sep 6, 2022 at 2:37 PM Martin Davis wrote:
> I've started to build out operations on Polygonal Coverages in JTS ([1],
> [
discarded without topology being built.
One option is to have two different signatures and implementations for the
Coverage Union operation, one on the suggested Coverage datatype, and a
fast one on a list of polygonal inputs.
On Tue, Sep 6, 2022 at 2:37 PM Martin Davis wrote:
> I've st
Actually I have been developing using the pattern that the output list is
1:1 with the input list, with null representing outputs which are not
present for some reason. Reasons for this are:
- works well with the "list of polygons" representation
- avoids any issues with creating/freeing userData
Thanks for the feedback, Nyall. Comments inline below.
On Tue, Sep 6, 2022 at 3:51 PM Nyall Dawson wrote:
> On Wed, 7 Sept 2022 at 07:37, Martin Davis wrote:
> >
> > I've started to build out operations on Polygonal Coverages in JTS ([1],
> [2]). These will be porte
I've started to build out operations on Polygonal Coverages in JTS ([1],
[2]). These will be ported to GEOS (started here with CoverageValidator
etc in C++ [3]). Hopefully these will be exposed in PostGIS as well (and of
course other downstream projects).
Here's some examples of coverage operatio
+1
On Tue, Jun 28, 2022 at 4:27 PM Paul Ramsey
wrote:
> 3.11.0beta2 has been out for a week, and no complaints. This is the vote
> on final release of 3.11.0
>
> +1 Paul
>
>
> P
>
>
> ___
> geos-devel mailing list
> geos-devel@lists.osgeo.org
> https:/
Also sounds familiar: in
https://github.com/geopandas/geo-arrow-spec/blob/main/format.md
Except for Points, empty geometries can be faithfully represented as an
empty inner list.
Empty points can be represented as POINT (NaN NaN).
On Thu, Jun 2, 2022 at 11:58 AM Martin Davis wrote:
> An
An ABI-stable C interface! Sounds eerily familiar :)
https://arrow.apache.org/docs/format/CDataInterface.html
On Thu, Jun 2, 2022 at 11:46 AM Paul Ramsey
wrote:
> They are coming for us, they are in the ceiling, they are in the room wtih
> us...
>
>
> https://dewey.dunnington.ca/post/2022/buil
As for testing, there is this GEOS issue recommending creating more C API
tests: https://github.com/libgeos/geos/issues/396
:)
On Thu, Feb 17, 2022 at 1:20 PM Jeff McKenna
wrote:
> Dear GEOS PSC,
>
> Great to hear about a grant to help the project along.
>
> My feedback is to make sure that th
I was thinking that some work on documentation would be great as well.
As developers it can be hard to know where to focus on what needs
documenting. Suggestions are welcome.
On Thu, Feb 17, 2022 at 1:20 PM Jeff McKenna
wrote:
> Dear GEOS PSC,
>
> Great to hear about a grant to help the projec
+1
On Wed, Feb 16, 2022 at 12:31 PM Paul Ramsey
wrote:
> I noticed that the GDAL CoC is in fact just the OSGeo CoC, which is
> convenient, as we are an OSGeo project.
>
> The code change is here.
>
> https://github.com/libgeos/geos/pull/568
>
> We already have a
> +1 Paul
> +1 Regina
> _
+1
On Thu, Jan 13, 2022 at 4:54 PM Paul Ramsey
wrote:
> I should roll a new patch release, any objections? Will do it either
> tomorrow or over the weekend.
>
> P
> ___
> geos-devel mailing list
> geos-devel@lists.osgeo.org
> https://lists.osgeo.org/ma
How stable is the web site?It's handy to have a global overview of the
CI, but if the web site is often unavailable that's not gonna help.
On Mon, Nov 1, 2021 at 11:40 AM Paul Ramsey
wrote:
> We've got big master CI tables on the trac, in the web site (that
> duplication will go away with
+1
On Fri, Oct 29, 2021 at 12:13 PM Paul Ramsey
wrote:
> http://libgeos.org/development/rfcs/rfc10/
>
> GitHub has been the largest source of 3rd party code contribution via
> pull-requests for some time now.
>
> Moving to Github has the following components:
>
> • Move the canonical (wr
put (Even Rouault)
> - Fix IsValidOp to correctly report invalid nested MultiPolygons (#1112,
> Martin Davis)
> - Fix BufferOp to avoid artifacts in certain polygon buffers (#1101,
> Martin Davis)
> - Declare parameterless functions in geos_c.h as func(void) (Paul Ramsey)
>
On Mon, Oct 18, 2021 at 2:27 PM Sandro Santilli wrote
>
> $ geosop help test
> terminate called after throwing an instance of 'std::invalid_argument'
> what(): stod
> Aborted (core dumped)
>
> I'd rather not install `geosop` than letting it core-dump so easily.
> It was ticketed as htt
+1
On Mon, Oct 18, 2021 at 1:34 PM Paul Ramsey
wrote:
> Having gone through numerous beta and rc releases, and hearing no
> further screams of agony, I call the vote on releasing 3.10.0.
>
> +1
>
> P
> ___
> geos-devel mailing list
> geos-devel@lists.
The naming of ConstrainedDelaunayTriangulation is deliberate. It *is* a
Constrained Delaunay Triangulation that currently works only on polygonal
inputs. The implementation of the Ear-Clipping algorithm is done in
PolygonTriangulator [1]. The ConstrainedDelaunayTriangulator uses that
triangulati
Constrained DelaunayTriangulation for polygonal geometry is now available
via geosop:
bin/geosop -a polygons.wkt -f wkt constrainedDelaunay
Performance is equivalent to the JTS version (which is very good). There
seems to be slowness on MultiPolygons for some reason - we'll look into
that soon.
An offshoot of the Ear-Clipping work is going to be a Concave Hull
algorithm for Polygons. It runs ear-clipping on the outside of the polygon
until some criteria is reached (either a target reduction in number of
vertices or limit to increase in area). This essentially "shrink-wraps"
the polygon.
I added a couple of images to the JTS PR:
https://github.com/locationtech/jts/pull/775
Blog post coming soon.
This triangulation implementation uses Ear-Clipping, so is only usable on
polygons. It would be nice to have an implementation for Constrained
Delaunay on linear inputs. The Tri data st
answer of 3.
Working on a fix now, and will file a GEOS issue.
On Fri, Sep 17, 2021 at 10:43 AM Martin Davis wrote:
> I agree with the analysis that there might be a problem with the Frechet
> Distance algorithm in GEOS. Although, there is a recent PR against JTS for
> Frechet Distan
I agree with the analysis that there might be a problem with the Frechet
Distance algorithm in GEOS. Although, there is a recent PR against JTS for
Frechet Distance with a different codebase, and it produces the same result
as the GEOS code. So this is puzzling.
The GEOS code is here:
https://gi
Posted as a public service for future reference.
While recovering from upgrading my Mac to Big Sur (which is a
whle 'nother rant), I upgraded to gcc-11 (using Homebrew). Sadly,
compiling GEOS then threw the following error message:
--
[ 29%] Build
The offset curve implementation is quite complex, so this could be a
challenge to debug. The code uses overlay (SnapOverlayOp), so my first
suspicion is that the change to OverlayNG in 3.9 has something to do with
this. But not sure why or how SnapOverlayOp would have been affected.
It will be use
Thanks for the bug report. I have replied on the original sf ticket:
https://github.com/r-spatial/sf/issues/1781#issuecomment-916260161
Quoted here for the benefit of this list:
There is a bug in GEOS 3.9.0 which causes overlay to essentially drop
straight lines if they are axis-parallel. It ver
Oh, of course, under the project site. Too early in the morning...
+1 from me.
On Mon, Aug 23, 2021 at 9:28 AM Martin Davis wrote:
> Under what GH account? If it's hosted under a personal account there is a
> bus factor issue.
>
>
> On Mon, Aug 23, 2021 at 9:08 AM Regina
Under what GH account? If it's hosted under a personal account there is a
bus factor issue.
On Mon, Aug 23, 2021 at 9:08 AM Regina Obe wrote:
> As Paul mentioned he already has put in work for a new geos site.
>
> Plan is to just host it on GH pages.
>
> I'll start with a +1 from me.
>
> Thank
+1 for flipping to OverylayNG
On Thu, Jul 15, 2021 at 11:01 AM Paul Ramsey
wrote:
> Just stumbled over this old stub,
>
> https://github.com/libgeos/geos/blob/main/capi/geos_ts_c.cpp#L1425
>
> In addition to GEOSUnaryUnion, which calls a cascaded union as required,
> we have this explicit hook i
The overlay operations do not necessarily preserve the exact sequence of
input vertices. This is the case for both GEOS and JTS. If you are seeing
a different, preferred order in JTS it's just by chance.
On Wed, Jul 14, 2021 at 7:46 AM Hector Nunez wrote:
> Hi,
>
> I found that the I use inter
JTS recently had a class called GeometryFixer added. The class provides
functionality to accept any invalid geometry and convert it to a valid
one. This plugs a noticeable gap in the JTS API!
Paul R has ported this to GEOS: https://github.com/libgeos/geos/pull/433
It performs a similar functio
+1
On Fri, Apr 9, 2021 at 11:16 AM Paul Ramsey
wrote:
> I'd like to do a release of 3.8.2, there is a shockingly large backlog and
> some crashers hiding in there and it's been 12 months, so I'm just going to
> get started and push the button tomorrow unless someone lights their hair
> on fire.
s needed.
On Tue, Feb 23, 2021 at 4:14 PM Greg Troxel wrote:
>
> Martin Davis writes:
>
> > I'm thinking about committing back-ported versions of geosop to 3.9, 3.8
> > and 3.7.
> >
> > Any objections? And any further objections if I don't bother with t
I am not intending to backport to 3.6
>
> Dan
>
> On Tue, Feb 23, 2021 at 2:16 PM Martin Davis wrote:
>
>> Hey GEOS devs,
>>
>> I'm thinking about committing back-ported versions of geosop to 3.9, 3.8
>> and 3.7.
>>
Hey GEOS devs,
I'm thinking about committing back-ported versions of geosop to 3.9, 3.8
and 3.7.
Any objections? And any further objections if I don't bother with the
autotools build setup?
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https:/
e ARM64 (Taras Zakharko)
> - Fix buffer to use largest enclosed area for invalid rings (#732, Paul
> Ramsey)
> - Preserve ordering of lines in overlay results (Martin Davis)
> - Fix overlay handling of flat interior lines (JTS-685, Martin Davis)
>
> That last one is quite a na
>
> It's not *tiny* but it's also not huge.
>
> P.
>
> Begin forwarded message:
>
> *From: *Martin Davis
> *Subject: **Re: [GEOSwift/GEOSwift] Invalid Intersection result after
> upgrading to GeoSwift 7.0.0+ (#212)*
> *Date: *January 27, 2021 at 12:21:3
The actual code change is quite small. Most of the code is fixing up the
test suite to accommodate it!
On Wed, Jan 27, 2021 at 12:46 PM Martin Davis wrote:
> I see no problem with back-porting to 3.9.
>
> On Wed, Jan 27, 2021 at 12:25 PM Paul Ramsey
> wrote:
>
>> How do
o not huge.
>
> P.
>
> Begin forwarded message:
>
> *From: *Martin Davis
> *Subject: **Re: [GEOSwift/GEOSwift] Invalid Intersection result after
> upgrading to GeoSwift 7.0.0+ (#212)*
> *Date: *January 27, 2021 at 12:21:39 PM PST
> *To: *GEOSwift/GEOSwift
> *Cc: *Paul
+1
On Wed., Jan. 13, 2021, 5:41 p.m. Daniel Baston, wrote:
> Hi,
>
> I'd like to thank everyone who contributed to the recent discussion of
> RFC-7 [1]. Considering the feedback received, and our early position in the
> release cycle, I do not anticipate problems from removing autotools for our
On Fri, Jan 8, 2021 at 2:45 PM Daniel Baston wrote
>
> I am not using autotools with GEOS but can't speak for others.
>
CMake for me, unless forced to run autotools.
It's quite a bit faster in GH CI too (unless autotools builds are doing
something additional)
___
Sounds like a great idea to me. As you say, supporting two build systems
is unproductive and buggy.
On Fri, Jan 8, 2021 at 9:25 AM Daniel Baston wrote:
> Hi,
>
> I'd like to propose that we revisit RFC 7 [1], introduced in October 2018,
> which proposes that we use CMake as the exclusive build
On Thu, Jan 7, 2021 at 4:55 PM Mike Taves wrote:
> Fantastic. I was about to suggest ryu too, so thanks for pursuing this
> approach.
Good to know!
> Amazing that float->string conversions is still a lively
> comp.sci. development scene, given that ryu is rather new (June 2018).
>
Well, it i
Paul's fine work on adding Ryu [1] finally makes WKTWriter numeric output
work as the API implies (i.e. precision means "decimal places" rather than
the C-style "significant digits"). This brings GEOS in line with JTS, and
more importantly makes it behave in a way that works better for geospatial
; andrew.d.hershber...@gmail.com> wrote:
> >>
> >>> For all these reasons and the fact that the current behaviour has
> existed for a long time and is now baked into downstream (those tests in
> GeoSwift!!) I'm inclined to just do nothing.
> >>
nges are to be made, I like the idea of doing
> - default, take the C++ defaults, don't apply anything. this is a change
> to current behaviour, which applies a default precision
> - if precision is specified, try to do a trimmed, fixed number of decimals
> output, which is kind of what my P
The improvement I'm suggesting can be obtained by setting
WKTWriter.setTrim(true) before use. I think this should become the
default, but it lets downstream projects work around this issue now.
On Wed, Jan 6, 2021 at 7:54 AM Martin Davis wrote:
> Well, yes. The current default behavio
if you say you do. Seems like time could be better spent
> elsewhere unless someone is paying for this functionality. Someone could
> certainly reprocess any WKT file to remove digits if they so chose.
> >
> > On Wed, Jan 6, 2021 at 10:25 AM Martin Davis wrote:
> > Is
Is it possible the problem is the use of std:fixed ? (Which is invoked if
the trim option = FALSE, which is the default).
Currently in WKTWriter.writeNumber there is this code (and the defaults
invoke fixed precision):
if(! trim) {
ss << std::fixed;
}
ss << std::setprecision(deci
And for the record, I am -10 on outputting scientific notation, except for
extremely large numbers (say > 10^20 - which should rarely occur in real
data). It just makes the output hard to read.
On Tue, Jan 5, 2021 at 4:35 PM Martin Davis wrote:
> setTrim and setRoundingPrecision ar
setTrim and setRoundingPrecision are GEOS-specific (not in JTS).
What JTS has is WKTWriter.setPrecisionModel(). What that does is to set
the max number of decimal places according to the precision supplied (e.g.
scale = 10 produces 1 decimal, scale = 100 produces 2, etc)
I like the simplicity o
+1
On Fri., Dec. 11, 2020, 2:34 a.m. Sandro Santilli, wrote:
> Release 3.6.3 came out in August 2018. Since then we have these
> fixes:
>
> Changes in 3.6.4
>
> - Bug fixes / improvements
> - Fix crash in GEOSUnaryUnion with empty LineString
> (#928, Sergey Fedoseev)
> - Fix in
+1
On Wed, Dec 9, 2020 at 8:46 AM Paul Ramsey
wrote:
> I am going to package a release today, and unless someone lights their
> hair on fire in the intervening 24 hours release tomorrow morning.
>
> P.
> ___
> geos-devel mailing list
> geos-devel@lists
Agreed about the need to handle each dimension of the input separately.
Polygonal elements need to be reduced in a topologically correct way using
OverlayNG PrecisionReducer, and other dimensions can just be reduced in
pointwise fashion.
I intended this logic to go into GeometryPrecisionReducer, r
Good point - I didn't see that additional semantic to your PR. No harm in
having such a method. Not sure about the naming, though.
On Sat, Nov 28, 2020 at 7:00 PM Daniel Baston wrote:
> Of all the design decisions made in the white heat of the development of
>> the initial release of JTS, the
On Sat, Nov 28, 2020 at 11:55 AM Paul Ramsey
wrote
>
> One thing I noticed when trying to construct GEOS envelopes directly was
> that annoyingly they were xmin xmax, ymin ymax, but I doubt that would be a
> problem in your pre-existing working test.
>
Of all the design decisions made in the whi
other performance work, that yielded relatively
> little in Debug might be bigger winners in Release...
> P.
>
> > On Nov 25, 2020, at 7:37 PM, Martin Davis wrote:
> >
> > Seems best to try a non-debug build...
> >
> > To run in JTS you can use:
> >
>
That will time only the operation, excluding the I/O.
On Wed, Nov 25, 2020 at 7:30 PM Paul Ramsey
wrote:
>
>
> > On Nov 25, 2020, at 6:41 PM, Martin Davis wrote:
> >
> > Actually OverlayNGRobust.unaryUnion will compare the current OverlayNG
> code to GEOS. However,
Actually OverlayNGRobust.unaryUnion will compare the current OverlayNG code
to GEOS. However, OverlayNG is likely to be slower, in any case.
So:
GEOS - 6.1 s
JTS 14.4 s
That's an impressive difference in favour of GEOS. I wonder why Paul's
timings are so different?
On Wed, Nov 25, 2020 at 6:00
+1 to dropping the SWIG bindings.
On Wed, Nov 25, 2020 at 1:37 PM Mike Taves wrote:
> Hi all,
>
> SWIG bindings have existed as part of the core GEOS library since
> early development, however they have not received much attention in
> many years.
>
> I've (quickly) prepared two options for cons
On Tue, Nov 24, 2020 at 3:44 PM Paul Ramsey
wrote:
>
> - Am I right that Z coordinates are nearly done? What's the status there?
>
I'm going to say that the JTS Z work is functionally complete. It
interpolates Z values where possible, and populates missing Z values from
an ElevationModel patter
On Fri, Oct 16, 2020 at 11:59 AM Roger Bivand wrote:
> Cases 794 and 936 are all-by-all intersections, and as noted in the latter
> issue, the problems occurring differ by input order.
>
Well, that's disappointing that 794 and 936 still have failures.
Especially because 794 was also reported as
On Thu, Oct 15, 2020 at 9:00 AM Roger Bivand wrote:
>
> Anyway, the failure count is very low, a half-dozen from hundreds is fine
> (and if they didn't write tests, that isn't our problem...).
>
What would be especially interesting is to see whether OverlayNG resolves
the various overlay robustn
As noted in a recent thread, it's tricky to create unit tests for overlay
operations. One reason for this is that the order of the result components
and coordinates is undefined, and so can vary between diifferent algorithms
and even different library releases. (The lack of well-defined ordering
That output is coming from HeuristicOverlay.cpp:
https://github.com/libgeos/geos/blame/c4aebbbc048618e75b39f6c8d85dce8e8216cf9f/src/geom/HeuristicOverlay.cpp#L206
It shouldn't be showing up unless GEOS_DEBUG_HEURISTICOVERLAY has been
enabled, however.
On Tue, Oct 13, 2020 at 11:40 AM Roger Bivand
Thanks for testing, Joris.
It makes sense that downstream project unit tests are focussed on the code
that is net new to the project. Still, it is always reassuring to run a
set of functional tests as well. One way to do this fairly easily would be
to develop a test runer that is able to exercise
Thanks for testing, Even.
Interestingly, in JTS the test case you give below for
OverlayNG.intersection actually returns the same result as the old code:
MULTILINESTRING ((833978.557030887 0, 835092.849076364 0),
(832864.275023695 0, 833978.556808034 0))
So this is something to look into on the
Hi. The algorithms in GEOS are almost all ported from the JTS Topology
Suite, fyi.
The reason for not having explicit documentation for algorithm complexity
is time/effort, and difficulty of proving the complexity.
In general the algorithms should be roughly O(n log n) (as opposed to the
O(n^2)
Would it be this one?
https://github.com/libgeos/geos/commit/bacd58058025b25de93fb23bb78ff540ef1e3b63
Paul was having some issues with output precision, but I can't remember the
details. He made some kind of fix - perhaps this one.
Agreed that the output in sci not for such small numbers is not
1 - 100 of 377 matches
Mail list logo
