+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
>
__
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:
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
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
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.
>
>
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
-
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel
--
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel
to the C API and the SWIG bindings...hopefully correctly.
I'll be happy to share those changes if the community wants them.
Since I'm not a committer, what would I do? Send patches to the list?
- Kevin
--------
ttle
effect with my given inputs, which would make perfect sense to me if
the edges overlap about as much as their floating point
representations allow.
- Kevin
On Nov 29, 2007, at 10:10 AM, Martin Davis wrote:
Leaving aside the snapping, I'm not too surprised that you're getting
thi
ead. :)
Thanks,
Allan
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel
--
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
determination of "frequent" 8^)
It's at: http://tsusiatsoftware.net/jts/jts-faq/jts-faq.html
Feel free to make suggestions for more content.
--
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022
___
geo
commutative, so you can't just exchange the order
of the parameters.
Martin Davis wrote:
The original code is correct as it stands. Your fix works because it
just removes a potential optimization.
The fix that Ben posted is the correct one (and has been implemented
in JTS as well).
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel
--
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022
_
t be used?
Thanks in advance.
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel
--
Martin Davis
Senior Technical Architect
Refractions
os-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel
--
Martin Davis
Senior Techni
s in the split_areas comparison)
Thanks,
Russell
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel
--
Martin Davis
Senior Technical A
nized. Am I correct? Is there some code that someone knows
about which could give me some *pointers.
Martin Davis wrote:
As you've noticed, the predicates are not necessarily consistent with
the overlay operations. This is because the predicates are exact,
whereas the overlay operations
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel
--
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022
___
geos-devel mailing list
geos-devel@lists.osgeo.org
ing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel
--
Martin Davis
Senior Technical Architect
R
it myself if I find the time in the future.
Bill
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel
--
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022
asked.
Greetings
--
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel
s.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel
--
Martin Davis
Senior Technical Architect
Refractions Research, Inc
Additionally, I would also like to nominate Mateusz Loskot for the GEOS PSC
membership list. His work has left a huge imprint on GEOS, and he's kept
things rolling through the various developmental lulls in the project after
Sandro left.
Howard
On Apr 3, 2008, at 1:01 PM, Martin Davis wr
Martin Chapman wrote:
Martin,
Here you go. It occurs when you union the US and Mexico. Thanks for your
help!
Best regards,
Martin
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Martin Davis
Sent: Thursday, April 03, 2008 12:32 PM
To: GEOS Develo
tinfo/geos-devel
--
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel
? Could I put a linearRing.isClosed() method call somewhere in the union code to trap the violating ring?
Thanks again for all your help!
Best regards,
Martin.
.
Sent via BlackBerry by AT&T
-Original Message-
From: Martin Davis <[EMAIL PROTECTED]>
Date: Fri, 04 Apr 2008 12:17:41
s,
P
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel
--
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022
___
geos-devel mailing list
geos-
__
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel
--
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022
___
geos-devel mailing list
geos-devel@lists.osgeo.o
f the remaining rings are gone.
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel
--
Martin Davis
Senior Technical Architect
Refractions
is no way I can get a shapefile with a valid multipolygon
inside it, I have to find a way to make it usable for GEOSIntersection.
2008/4/28 Martin Davis <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>:
When I look at the geometry fragment you provided, the "hole"
and applying a GEOSBuffer to each
one of them when needed, but this doesn't work either because
many of the resulting polygons are screwed up, and I can't
discard any of them. Also there is no way I can get a
shapefile with a valid multipolygon inside
?
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel
--
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022
___
geos-devel mailing list
geos-devel
;changeset=on
Best regards
--
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel
I have read, understood and will follow RFC2
Martin
Paul Ramsey wrote:
I also read, understand and will follow RFC2.
The following people need to affirm the same:
* pramsey - Paul Ramsey (124, 2007-12-21)
* mbdavis - Martin Davis (1, 2003-02-11)
* hobu - Howard Butler (17, 2006
---
_______
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel
--
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel
prep geom.
Any suggestions?
Best regards,
--
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel
el"
which might be used by a coder using the C++ API. Perhaps there should
be a warning about this (in the non-existent FAQ?)
M
Mateusz Loskot wrote:
Martin Davis wrote:
I would think that there should be a destructor defined for the
PreparedGeometry class. Would this be the appropri
Sure, sounds good - I agree with your reasoning. Simpler is better!
Mateusz Loskot wrote:
Martin Davis wrote:
Ugh.
Sounds like we need a
PreparedGeometryFactory::destroyPreparedGeometry(PreparedGeometry *)
method, then - as per your suggestion.
or just
PreparedGeometryFactory::destroy
stroyed, yes?
Can saner heads than me confirm my analysis?
P.
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel
--
Martin Davis
Senior Technical Architect
Refrac
s thinking that the blunt-force solution would be to clone the
Geometry when PreparedGeometry is constructed, rather than retaining a
reference, so we an delete the whole kit-n-kaboodle when we're done
with the PreparedGeometry.
P.
On Mon, Aug 18, 2008 at 7:15 PM, Mateusz Loskot <[EMAIL PR
.osgeo.org/mailman/listinfo/geos-devel
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel
--
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022
MAIL PROTECTED] On Behalf Of Martin Davis
Sent: Wednesday, September 17, 2008 2:24 PM
To: GEOS Development List
Subject: Re: [geos-devel] OverlayOp JTS port
The original plan for GEOS was that it would track JTS 100%. This was
to simplify porting new functionality as it is added to JTS. Howeve
e kinds of things :)
P.
On Wed, Sep 17, 2008 at 2:33 PM, Martin Davis <[EMAIL PROTECTED]> wrote:
I can confirm - if GEOS is doing something with computing new Z-values this
is something which is NOT in JTS. I vaguely recollect that this is
something which Sandro added.
Obe, Regina wrote:
collector.
GCJ uses the bohem one, and is very nice.
Ever tried to build JTS natively ?
--strk;
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel
--
Martin Davis
Senior Technical Architect
//lists.osgeo.org/mailman/listinfo/geos-devel
--
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel
.osgeo.org/geos/ticket/207
[2] http://trac.osgeo.org/geos/ticket/207#comment:4
Best regards,
--
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel
at the same time.
ATB,
Mark.
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel
--
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022
_
anslated by a
preprocessor to real code.
IMO, I don't see this as being viable for a codebase as complex as
GEOS. I think it would be very hard to debug the "high-level" preproc
instructions, given that you'd have to debug them at the
processed-source level.
But I&#x
list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel
--
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailma
* Help make the earth a greener place. If at all possible resist
printing this email and join us in saving paper. *
* *
* *
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/
elp on the history behind this global?
P.
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel
--
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250
rent code.
void
finishGEOS ()
{
// Nothing to do
//delete geomFactory;
}
Any help on the history behind this global?
P.
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel
--
Mart
.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel
--
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022
_
--
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel
--
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022
-
_______
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel
--
Martin Davis
Senior Technical Architect
Refractions Researc
02675.html
It might be of interest to consider porting this over to GEOS (before
the upcoming release?). It's a relatively minor port - 1 class and
about 20 lines of calling code. I can give specific details if required.
Martin
--
Martin Davis
Senior Technical Architect
Refractions Rese
o.org
http://lists.osgeo.org/mailman/listinfo/geos-devel
--
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel
ist
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel
--
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel
-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel
--
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http
ing it. Also I would add links to OSGeo
page point to the wiki page, and maybe some of the other projects that
use GEOS and are also in wikipedia.
-Steve
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo
And there's already a page at
http://en.wikipedia.org/wiki/JTS_Topology_Suite
Martin Davis wrote:
And a link to JTS would be good too. And it's the JTS Topology Suite,
not the Java Topology Suite, for copyright reasons.
Stephen Woodbridge wrote:
strk wrote:
I've stubbe
s law. It is intended
solely for the addressee. If you received this in error, please
contact the sender and delete the material from any computer.
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel
nominating Steven as a
committer.
Paul
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel
--
Martin Davis
Senior Technical Architect
Refractions Researc
paper. *
* *
* *
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel
--
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383
osgeo.org>
http://lists.osgeo.org/mailman/listinfo/geos-devel
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel
--
Martin Davis
S bug or simply a problem with behaviour > 2
dimensions being undefined?
ATB,
Mark.
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel
--
Martin Davis
Senior Technical Architect
Refract
doing for us?
P.
--
Paul Ramsey
OpenGeo - http://opengeo.org
PostGIS. Because you're just that good looking.
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel
--
Martin Davis
Senior
anks,
Ben
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel
--
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250
devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel
--
Martin Davis
Senior Technical A
I would have expected so - so I'm puzzled. No further ideas at the
moment, I'm afraid.
Paul Ramsey wrote:
I can do an individual union of Mozambique and Zimbabwe without
problems. Should I be seeing a topology exception?
P
On Thu, Jan 29, 2009 at 12:09 PM, Martin Davis wrote:
Jo
--
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel
:TopologyException will be
throwed.
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel
--
Martin Davis
Senior Technica
LINUX
10.1 (X86-64).
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel
--
Martin Davis
Senior Technical Architect
R
: |
+---
--
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel
(libgeos version 3.0.3) with an
equivalent code written in C (so I think Shapely is not involved).
Any idea ? Did I miss something ?
Pascal
_______
geos-devel mailing list
geos-devel@lists.osge
n error.
It's good to learn that geometry collection predicates aren't
supported.
On Mar 16, 2009, at 9:46 AM, Martin Davis wrote:
GEOS does not support evaluating predicates on
GEOMETRYCOLLECTIONS (due to the potential complexity and lack
of obvious
#x27;w'), buffer_1.wkb.encode('hex')
>>> print >> open('buffer_2.hexwkb','w'), buffer_2.wkb.encode('hex')
}}}
On MacOSX, libgeos 3.0.0, with an equivalent code in C, the problem occurs
too.
-----
?
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel
--
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022
___
geos-devel
icket.
Thanks,
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel
--
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
icket.
Thanks,
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel
--
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
strk,
I'm unable to login to the GEOS trac right now, so I'm following up on
the list.
I didn't build an actual test case, I just tried it in the TestBuilder.
But adding this as a test case is a good idea!
strk wrote:
On Mon, Jul 06, 2009 at 09:44:40AM -0700, Martin Davis
-
or is there a misunderstanding on my part?
Bye
Frederik
--
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel
t-us...@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel
--
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-302
y
be more oriented to this arena which would explain the 45/90 degree
stuff I noticed.
Anyway maybe something to keep an eye on as it evolves or something
that you might want to comment on in their review process.
Best regards,
-Steve
Martin Davis wrote:
Interesting and ambitious project.
4.672 seconds
These results are colored by the check of the area. Checking without gives:
100 points per ellipse:
-> geos time: 13.437 seconds
-> ggl time: 1.140 seconds
-> gpc time: 9.047 seconds
-> polygon time: 38.688 seconds
-> terralib time: 4.609 second
plating and operator overloading - would it be possible to
define a DSL using C++ constructs which would allow GEOS to be compiled
more efficiently?
Martin
Mateusz Loskot wrote:
Martin Davis wrote:
Hmmm... GEOS comes off rather badly compared to GGL. Is that because
of memory access issues?
any way of avoiding dynamic
allocation, since there's no way to predict a priori how many line
segment intersections will be found, or how what the structure of the
output geometry is. Does GGL avoid this problem in some way?
Barend Gehrels wrote:
Martin Davis wrote:
Ok, I can see that. So
fts). However, it requires somewhat more
bookkeeping. So intersected polygons are assembled in the end, in
between there are no large pieces of memory allocation.
JTS/GEOS uses the same approach. As you say, it's more efficient to
collect the intersection points first and then create the split edges.
some semantic
rewriting required for maximum optimization. But I'd be happy for
someone to prove this conjecture wrong 8^)
--
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022
___
geos-devel mailing list
g
his is the
most time-consuming part of overlay computation. A simplistic
implementation is O(n^2), but there are a variety of techniques which
can be used to improve this. Can you comment on the approach GGL uses
for intersection determination?
Martin
--
Martin Davis
Senior Technical Architect
R
Sounds like you've got all the right ideas, Barend. Good luck with the
optimizations...
Martin
Barend Gehrels wrote:
Hi Martin,
I was on holiday, therefore my delay in answering your question.
Martin Davis wrote:
Barend Gehrels wrote:
The GGL overlay algorithm will be described
d.
It could be interesting to investigate what went wrong with those tests.
[1] http://lists.boost.org/boost-users/2009/11/53451.php
--
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022
___
geos-devel mailing
as it competes with
them elsewhere.
Yes, definitely it's nice to have examples of how things can be improved.
Personally I intend to stay well away from any C++ template hacking, though!
--
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250
, VS pure algorithm design. The
latter can inform other libraries - the former, not so much.
Martin Davis wrote:
Maxime van Noppen wrote:
It's quite interesting to have some numbers though, as sometimes they
can lead to significant performance boost (CascadedPolygonUnion is a
good example
rithm from implementation.
P.
On Wed, Nov 18, 2009 at 9:32 AM, Paul Ramsey wrote:
Probably something as simple as running Maxime's test polygons and
watching the profile in Shark would give the answer, since the
difference is so huge.
P.
On Wed, Nov 18, 2009 at 9:39 AM, Martin Davis wrote:
Ma
ler (no inlining and no global
optimization possible). But this alone shouldn't result in magnitudes of
performance differences.
Regards Hartmut
---
Meet me at BoostCon
http://boostcon.com
Martin Davis wrote:
Maxime van Noppen wrote:
It's quite int
sized? Doesn't the dynamically created memory get allocated from the
heap?
--
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022
--
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022
_
, 2009 at 2:38 PM, Martin Davis wrote:
Hartmut Kaiser wrote:
It's not that allocation is necessarily slow
Well, compared to the JVM it is. Java is amazingly fast at allocating
objects.
Sharing is certainly a bit trickier this way, but allocating on the stack
ely for the addressee. If you received this in error, please
contact the sender and delete the material from any computer.
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel
--
Martin Davis
S
sts.osgeo.org [geos-devel-boun...@lists.osgeo.org]
On Behalf Of Martin Davis [mbda...@refractions.net]
Sent: Thursday, January 21, 2010 5:53 PM
To: GEOS Development List
Subject: Re: [geos-devel] Topology Exception with nested collections
JTS/GEOS does not support unioning GeometryCollections. N
1 - 100 of 368 matches
Mail list logo
