Not sure how
PostGIS is sidestepping this problem - perhaps it just ignores it?
One issue is that just because a GeometryCollection of Polygons is valid
does not mean that the set of Polygons would form a valid MultiPolygon
(they might overlap). In this case you would see this kind of failure.
O
I'm actually not sure if this is a bug or not, but I always thought in a
perfect world that if I union two valid geometries, I should not get errors. I
get a bunch of these in my torture tests (both against 3.1.1 and 3.2.0 GEOS)
and verified they pass the ST_IsValid test.
One of these cases s
ttp://www.mapwindow.org/>
2009/12/8 Mateusz Loskot mailto:mate...@loskot.net>>
Obe, Regina wrote:
> Paul,
>
> Geos 3.1.1 had missing files for VS. I believe if you pull from SVN
> you get all the missing files.
Yes, it should be fixed in the trunk:
http://trac.osgeo.org/geos/ti
Paul,
Geos 3.1.1 had missing files for VS. I believe if you pull from SVN you get
all the missing files.
On another note. GEOS 3.2 is coming out really soon -- its up to RC3 and
Mateusz has been working really hard to make sure all the pieces are packaged
in there to compile from the tar bal
9, 2009 4:41 PM
To: Mateusz Loskot; Obe, Regina
Cc: GEOS Development List
Subject: {SPAM: 40} :Re: autogen.bat
On Tue, Nov 17, 2009 at 11:16:28PM +, Mateusz Loskot wrote:
> I assumed that GEOS distribution is supposed to already
> provide generated and valid version.h and platform.h and
GEOS Development List
Subject: Re: [geos-devel] 3.2.0rc1 tagged
Yes, VC users must remember to run autogen.bat before starting...
P
On Fri, Nov 13, 2009 at 1:29 PM, strk wrote:
> On Fri, Nov 13, 2009 at 04:13:14PM -0500, Obe, Regina wrote:
>>
>
>> Now for VC++ 2009 express, I tried c
I think this is on the todo so I'm not really complaining. But make check
doesn't work under MingW, but hasn't for a while anyway.
Now for VC++ 2009 express, I tried compiling and it seems I need inttypes.h? I
don't recall that being a dependency before (GEOS 3.1) or maybe I always had
it be
Strk,
Any chance you are going to make this available as a download file on the
website?
A lot of people just go for the tar, especially if you don't have svn client
installed on your server. So making sure the download file is well packaged
and can be compiled I consider part of a good test s
Yes -- read our instructions on PostGIS section 10. You have to edit
some MingW stuff.
http://trac.osgeo.org/postgis/wiki/UsersWikiWinCompile
Hope that helps,
Regina
From: geos-devel-boun...@lists.osgeo.org
[mailto:geos-devel-boun...@lists.osgeo.org] On Beh
We have similar issues with compiling under nmake.
I can successfully compile with nmake VC 2005 the svn branches/3.1
but the tar ball is a no go
its missing nmake.opt
among other things --
This is just my own ineptness, but not sure how to do a make check on an
nmake built one.
If I use the
both 3.1.1rc1 and 3.0.4rc1 compile and pass tests under OpenSUSE 11
gcc version 4.3.1 (prelease) revision 135036
-
The substance of this message, including any attachments, may be
confidential, legally privileged and/or exempt from disclosure
pursuan
: Sat 6/13/2009 11:46 AM
To: GEOS Development List
Subject: Re: [geos-devel] 3.1.1rc1 and 3.0.4rc1 fail under VS 2008
Do GEOS 3.1.0 or 3.0.3 pass?
On Sat, Jun 13, 2009 at 8:41 AM, Obe, Regina wrote:
> geos-3.1.1rc1 -- fails under Visual Studio 2008. well at least for me
> anyway.
>
&g
being added to the tar.
I'm trying to recompile the geos 3.1.1rc1 tar now.
-Original Message-
From: geos-devel-boun...@lists.osgeo.org on behalf of Obe, Regina
Sent: Sat 6/13/2009 12:34 PM
To: GEOS Development List
Subject: RE: [geos-devel] 3.1.1rc1 and 3.0.4rc1 fail under VS 2008
Weir
ginal Message-
From: geos-devel-boun...@lists.osgeo.org on behalf of Obe, Regina
Sent: Sat 6/13/2009 12:10 PM
To: GEOS Development List
Subject: RE: [geos-devel] 3.1.1rc1 and 3.0.4rc1 fail under VS 2008
Paul,
Haven't tried 3.0.3 but the 3.1.0 tar ball fails too with similar errors. I
usual
un 13, 2009 at 8:41 AM, Obe, Regina wrote:
> geos-3.1.1rc1 -- fails under Visual Studio 2008. well at least for me
> anyway.
>
>
> 1) capi unit is still referencing GEOSGeomToWKB... - I think Mateuz said
> this should not be in 3.1.1 -- just in 3.2? I took it out, but every
geos-3.1.1rc1 -- fails under Visual Studio 2008. well at least for me anyway.
1) capi unit is still referencing GEOSGeomToWKB... - I think Mateuz said this
should not be in 3.1.1 -- just in 3.2? I took it out, but everything still fails
2)badthreadtest.c, threattest.c, geostest.c -- have a bi
its just seems to be the make check that is problematic as far as I
can tell.
-Original Message-
From: geos-devel-boun...@lists.osgeo.org
[mailto:geos-devel-boun...@lists.osgeo.org] On Behalf Of Obe, Regina
Sent: Friday, June 12, 2009 8:54 AM
To: GEOS Development List
Subject: RE: [geos
g] On Behalf Of Obe, Regina
Sent: Friday, June 12, 2009 8:00 AM
To: GEOS Development List
Cc: Mark Cave-Ayland
Subject: RE: [geos-devel] 3.1.1rc1 and 3.0.4rc1
So in conclusion
make check on MingW -- 3.1.1rc1 -- barely gets in the door (I think it
passed one test before vomitting)
3.0.4rc1 make
OpenSUSE 10.3
3.1.1rc1 -- compiles and make check passes with flying colors on
OpenSUSE 10.3
3.0.4rc1 -- compiles and make check passes with flying colors on
OpenSUSE 10.3
-
The substance of this message, including any attachments, may be
confidential, leg
So in conclusion
make check on MingW -- 3.1.1rc1 -- barely gets in the door (I think it
passed one test before vomitting)
3.0.4rc1 make check -- chugs along for a while ang then geos_unit.exe
crashes with message
creating geos_unit.exe
.libs/lt-geos_unit.exe.c: In function `main':
.libs/lt-ge
---
From: geos-devel-boun...@lists.osgeo.org
[mailto:geos-devel-boun...@lists.osgeo.org] On Behalf Of Paul Ramsey
Sent: Thursday, June 11, 2009 9:29 AM
To: GEOS Development List
Subject: Re: [geos-devel] 3.1.1rc1 and 3.0.4rc1
I'm tempted to release on the basis of this news alone :) don't l
3.0.4rc1 tar ball also seems to compile okay under MingW
-Original Message-
From: geos-devel-boun...@lists.osgeo.org
[mailto:geos-devel-boun...@lists.osgeo.org] On Behalf Of Paul Ramsey
Sent: Wednesday, June 10, 2009 12:16 PM
To: GEOS Development List
Subject: [geos-devel] 3.1.1rc1 and 3.
I tried compiling geos-3.1.1rc1.tar.gz under MinGW and IT COMPILED.
though strangely can't get checkout from branch SVN to compile and also
can't compile the trunk tar ball. I forget what error I get with that.
Haven't tried compiling 3.0.4rc1 yet.
-Original Message-
From: geos-devel-
--Original Message-
From: geos-devel-boun...@lists.osgeo.org
[mailto:geos-devel-boun...@lists.osgeo.org] On Behalf Of Mateusz Loskot
Sent: Monday, June 01, 2009 4:31 AM
To: GEOS Development List
Subject: Re: [geos-devel] tests\unit\capi\GEOSGeomFromWKBTest.cpp
missing
Obe, Regina wrote:
>
&g
Was the tests\unit\capi\GEOSGeomFromWKBTest.cpp removed. I'm trying to compile
under visual studio 2008 with the msvc9 solution provided and this apparently
has link to this and says it doesn't exist.
I don't see it in that folder so assume it should just be removed from the
solution.
ory `/D/SVNProjects/geos/3.0/source/algorithm'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/D/SVNProjects/geos/3.0/source'
make: *** [all-recursive] Error 1
-Original Message-
From: geos-devel-boun...@lists.osgeo.org
[mailto:geos-devel-boun...@lists.osge
...@lists.osgeo.org] On Behalf Of Paul Ramsey
Sent: Thursday, May 28, 2009 11:32 AM
To: GEOS Development List
Subject: Re: [geos-devel] 3.0.
I don't know what to say, you aren't getting a compile error, that's a
linking error. If you make clean, does the error recur in the same
exact p
geos trunk (3.2) seems to compile and pass check tests under OpenSUSE
10.3.
Thanks,
Regina
-Original Message-
From: geos-devel-boun...@lists.osgeo.org
[mailto:geos-devel-boun...@lists.osgeo.org] On Behalf Of Paul Ramsey
Sent: Wednesday, May 27, 2009 3:27 PM
To: GEOS Development List
Sub
ues.h:41: warning: 'putInt'
declared `static' but never defined
../../source/headers/geos/io/ByteOrderValues.h:43: warning: 'getLong'
declared `static' but never defined
../../source/headers/geos/io/ByteOrderValues.h:44: warning: 'putLong'
declared `static'
Paul,
Geos trunk doesn't compile for me under MingW. Haven't tried under VS
2008 yet.
I haven't done a clean checkout so will try that next, but this is what
I get under MingW, after doing an sh autogen.sh (maybe I need to upgrade
my auto conf again)
$ sh autogen.sh
* Running /mingw/bin/libtooliz
Paul,
Under OpenSUSE 10.3 -- I have similar issue with trying to compile geos
3.0 branch but with different file.
To get to that point I did a fresh checkout
svn checkout http://svn.osgeo.org/geos/branches/3.0 geos30
cd geos30
sh autogen.sh
./configure
make & make install
The autogen looks fa
Paul,
I don't seem to be able to compile this under OpenSUSE 10.3. Haven't
tried under my windows box yet.
To get to that point I did a fresh checkout
svn checkout http://svn.osgeo.org/geos/branches/3.1 geos31
cd geos31
sh autogen.sh
./configure
make & make install
(Did I miss a step?)
The au
egina
-Original Message-
From: geos-devel-boun...@lists.osgeo.org on behalf of Obe, Regina
Sent: Tue 4/14/2009 11:05 PM
To: GEOS Development List
Subject: [geos-devel] Something wrong with GEOSEnvelope function in 3.1.0?
LiN ,
I'm using GEOS 3.1.0 as well. However on further inspection it
LiN ,
I'm using GEOS 3.1.0 as well. However on further inspection it looks like
PostGIS uses its own implementation of Envelope and not the GEOS one, so you
could very well be right that there is something wrong with that GEOS function.
Unfortunately I don't know enough about GEOS to test it a
Oops typo I meant
LINESTRING(1 3,1 6)
envelope gives back the same thing
LINESTRING(1 3,1 6)
-Original Message-
From: geos-devel-boun...@lists.osgeo.org on behalf of Obe, Regina
Sent: Tue 4/14/2009 12:17 AM
To: GEOS Development List
Subject: RE: [geos-devel] question about GEOSUnion
ail/geos-devel/attachments/20090413/38a437e5/attachment-0001.html
>
> --
>
> Message: 2
> Date: Mon, 13 Apr 2009 01:32:38 -0400
> From: "Obe, Regina"
> Subject: RE: [geos-devel] question about GEOSUnion?
> To: "GEOS Development List&q
LiN YongHeng,
your geometry is invalid since first you don't have enough points to form a
polygon after you remove the dupes and second you have self intersections.
Therefore the union is undefined at best.
Hope that helps,
Regina
-Original Message-
From: geos-devel-boun...@lists.osg
Jo,
Not sure if this helps but I think Bruce posted a PostGIS solution to at
least the smallest circle that encloses a polygon. Not sure if you can
use it, but might give you some ideas how to go since PostGIS piggy
backs on GEOS.
http://postgis.refractions.net/pipermail/postgis-users/2008-Octob
This is just an observation. I've seen a lot of these type failures in my
garden tests and just ignored them.
This for example happens often if you in PostGIS create a MULTIPOLYGON by
collecting valid polygons that happen to intersect in some way
and then pass this to ST_Union. Those are inval
x27;t
compileGeos3.1underOpenSUSE anymore, compiles okay under Vc2005 with
changes
Does this help?
On Wed, Jan 14, 2009 at 9:27 AM, Obe, Regina
wrote:
> Evidentally we had the same issue with CLocalizer and the use of
strdup
> was removed. Not sure if that is the right solution though.
>
> http://tr
n if I'm not mistaken, and that's included at the
top of the file. So why is it not being picked up? You are even using
the gnu toolchain, so all the more reason you should have consistent
behavior to the linux/osx builds.
P.
On Wed, Jan 14, 2009 at 5:05 AM, Obe, Regina
wrote:
> Pau
Well from my observation it looks like most of those Ops functions (not
sure about Union and Intersection) -- first do a 2D operation and then
do some sort of apply the Z back on. So the Z is never considered in
the basic operation -- thus the cause of a lot of the goofiness.
Take this example.
t List
Subject: Re: [geos-devel] RE: [postgis-devel] Can't compile Geos
3.1underOpenSUSE anymore
Doesn't make much sense to me. is #include'd, so...?
On Tue, Jan 13, 2009 at 7:54 AM, Obe, Regina
wrote:
> Okay that fixed my OpenSUSE compile problem.
>
> On MingW, getting a
thm. This algorithm appeared in JTS for some reason which is
>> lost in the mists of time. AFAIK it's never really been used or
>> tested extensively.
>> It probably postdated the initial port of GEOS, and I guess nobody
>> went looking for it until now...
>
ng to entice them to
document the 3D functions?
Sean
On Jan 12, 2009, at 12:49 PM, Obe, Regina wrote:
> I looked at the GEOS code a while back and compared to JTS and
> was shocked that I saw GEOS z (as I call it smurf code and did not see
> this smurf code in JTS).
>
> This
eck-in. Fixed at r2233.
P.
On Tue, Jan 13, 2009 at 7:02 AM, Obe, Regina
wrote:
> Mark,
>
> Good thought. I can't remember if I did an autogen or not, but just
did
> and my OpenSUSE is still compiling.
>
> My MingW install which I did do an sh autogen.sh , configure, ma
2009 9:45 AM
To: PostGIS Development Discussion
Subject: Re: [postgis-devel] Can't compile Geos 3.1 under OpenSUSE
anymore
Obe, Regina wrote:
> I assume this is because of the recent changes. I did an svn up and a
> reconfigure and then compile under OpenSUSE.
>
> I get thi
Oops sent to wrong dev group last time.
-Original Message-
From: Obe, Regina
Sent: Tuesday, January 13, 2009 9:40 AM
To: 'PostGIS Development Discussion'
Subject: Can't compile Geos 3.1 under OpenSUSE anymore
I assume this is because of the recent changes. I did
M
To: GEOS Development List
Subject: Re: [geos-devel] C API coordinate sequence dimensions
Thanks, Regina, that hints that the supporting GEOS C API functions
might be considering z, but then again, the 3D might be implemented in
the PostGIS lib.
On Jan 12, 2009, at 12:18 PM, Obe, Regina wrote:
> A
A lot of these are catalogued here
http://postgis.refractions.net/documentation/manual-svn/ch08.html#id2671967
and
ST_Union and I just discovered even ST_BuildArea.
ST_ConvexHull (but that in my opinion gives goofy results).
Though still debating how to describe that their results are debate
I was snooping around the GEOS library and noticed a curious algorithm class
called MinimumDiameter. As far as I can tell from scanning the code,
it seems similar in concept to the the Minimum Bounding Circle plpgsql
algorithm that
Bruce posted in November
http://postgis.refractions.net/pipermai
hink to make a patch because
of the new files I was adding. This time I went ahead and did an svn
add just to be able to take a good patch.
And yes, this was done in Trunk and not a branch.
I've attached the new patch file to the ticket.
Thanks again,
Chuck
On Fri, 2008-11-28 at 19:19 -05
Chuck,
This is all fairly new to me so I could be missing something here. I'm having
trouble compiling these new changes you have under Visual Studio 2008
1) First off all, it looks like you provided the changed files rather than a
patch. Shouldn't you have provided a patch instead?
2) I pres
Doesn't GDAL use it too. We should link to the GDAL page as well
http://en.wikipedia.org/wiki/GDAL
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Stephen
Woodbridge
Sent: Wednesday, November 12, 2008 11:25 AM
To: [EMAIL PROTECTED]
Subject: Re: [geos-de
S Test
Builder"-like user interface).
Please look forward to it!
Regards,
2008/10/25 Obe, Regina <[EMAIL PROTECTED]>
Paul,
Can you try applying this revised attached patch. I ran into
the same
issues you described when trying to apply the tortoise gener
;m suspecting my
OS/X patch is (a) first stripping the CRs from the dos-generated patch
and then (b) not finding any matches in the dos-formatted target file.
I think someone else with a cygwin sandbox should apply this patch.
P.
On Fri, Oct 24, 2008 at 8:46 AM, Obe, Regina <[EMAIL PROTECTED]>
patch
and then (b) not finding any matches in the dos-formatted target file.
I think someone else with a cygwin sandbox should apply this patch.
P.
On Fri, Oct 24, 2008 at 8:46 AM, Obe, Regina <[EMAIL PROTECTED]>
wrote:
> Paul,
>
> The earlier one doesn't add any new files so m
lution.
Thanks,
Regina
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Paul Ramsey
Sent: Friday, October 24, 2008 11:39 AM
To: GEOS Development List
Subject: Re: [geos-devel] 3.0.3 To Do
On Thu, Oct 23, 2008 at 9:48 PM, Obe, Regina <[EMAIL
ION_MINOR 3
> +#define GEOS_CAPI_VERSION_MINOR 4
> #define GEOS_CAPI_VERSION_PATCH 3
> -#define GEOS_CAPI_VERSION "3.0.0rc4-CAPI-1.3.3"
> +#define GEOS_CAPI_VERSION "3.0.3-CAPI-1.4.3"
> #else
> #define GEOS_VERSION_MAJOR @VERSION_MAJOR@
> #define GEOS_VERSION_
define GEOS_CAPI_VERSION_PATCH 3
> -#define GEOS_CAPI_VERSION "3.0.0rc4-CAPI-1.3.3"
> +#define GEOS_CAPI_VERSION "3.0.3-CAPI-1.4.3"
> #else
> #define GEOS_VERSION_MAJOR @VERSION_MAJOR@
> #define GEOS_VERSION_MINOR @VERSION_MINOR@
> ---
>
> Regards,
>
&g
CAPI-1.3.3"
+#define GEOS_CAPI_VERSION "3.0.3-CAPI-1.4.3"
#else
#define GEOS_VERSION_MAJOR @VERSION_MAJOR@
#define GEOS_VERSION_MINOR @VERSION_MINOR@
---
Regards,
2008/10/24 Frank Warmerdam <[EMAIL PROTECTED]>
> Obe, Regina wrote:
>
>> I know Frank already tes
I tried Sanak's patch on my Visual Studio 2005 Professional install, and
it seemed to fix my compile problems.
Also ran the tests and they all seemed to pass - test output below in
case I misread something.
I know Frank already tested on Visual C++ Express (which is basically
Visual 2008 Expres
st
Subject: Re: [geos-devel] 3.0.3 To Do
No, I'm pretty sure he said he'd do it when he got time.
P
On Wed, Oct 22, 2008 at 12:04 PM, Obe, Regina
<[EMAIL PROTECTED]> wrote:
> Didn't Mark Cave-Ayland already do that and say it worked?
>
&
your patch already... so, I
guess we just need a Windoze volunteer to compile branch 3.0.
P.
On Wed, Oct 22, 2008 at 11:58 AM, Obe, Regina <[EMAIL PROTECTED]> wrote:
> Wasn't the CLocalizer change in trunk already. It should have been in my
> patch since I took the CLocalizer.cp
Wasn't the CLocalizer change in trunk already. It should have been in my patch
since I took the CLocalizer.cpp and .h from trunk since I couldn't get it to
compile otherwise. Or hmm I think I that was the one that I couldn't just add
the header line.
From: [E
Mark et. al,
Not sure it matters - hmm I forget which file it was. I probably should
have taken notes, but the include listings were in a different order
from the trunk. I added the missing one I think cstring or was it
version, but was hesitant to change the order of the includes to match
trunk
Sean,
Not sure how far you got. But the patch I submitted contains the below
backport and the gcc-4.3 fixes.
Mark has tested and said it fixes the MingW issues too. I have tested on
OpenSuse 11 gcc 4.3dev something or other and seems to compile fine.
Thanks,
Regina
-Original Message-
Mark,
> Way to go Regina!
> I just applied your patch to the GEOS 3.0.2 and this fixes compilation
> under both Debian Lenny gcc-4.3 and MingW :)
Thanks - I almost feel brave enough now to try to port some of that JTS
stuff to GEOS.
> Note: I still see some XMLTester warnings like this:
Yap I
Okay here is my complete patch. I'm still fussing with my install to get my
postgis compile to take the new GEOS (insists on hanging on to the 3.1.0), but
the GEOS 3.0.2 with the attached seems to compile fine on my OpenSUSE 11 vm.
Like I mentioned before - many file changes, mostly adding head
is
my revised patch.
Mark - thanks for the vote of confidence. I almost feel like I know what I am
doing :)
Thanks,
Regina
-Original Message-
From: [EMAIL PROTECTED] on behalf of Obe, Regina
Sent: Sun 10/19/2008 10:33 PM
To: PostGIS Development Discussion; PostGIS Development Dis
t: Re: [postgis-devel] 1, dot, 3 dot 4!
Well, unless someone else (Mat?) can apply this patch back into 3.0
and test it, or you can work it up Regina, it'll have to wait until I
get home and set up a VM with a new debian in it that has the new gcc.
P
On Sun, Oct 19, 2008 at 4:06 PM, Obe, Regi
Paul,
Sounds like a plan.
Regarding the kml failure. I tried to be lazy by
1) copying my Open SUSE 11 vm.
2) downgrade to 1.3.3
3) ran make check and it failed on kml check again. So I assume the kml thing
is nothing to worry about.
(But oops wait a minute reads 1.3.3 with GEOS 3.1.0. I as
Okay I pulled directly from svn did the usual
sh autogen.sh
./configure
make
The one from svn seems to work fine, so what's the deal with the nightly
svn snapshot?
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Obe, Regina
Sent: Friday, Octob
Is there something different about the way I should be compiling 3.1.0.
I was hoping to test the new changes out on some of my datasets. So I
compiled the same way I did with 3.0.0
Basically download latest svn nightly snapshot from
http://download.osgeo.org/geos/geos-svn.tar.bz2
Extract
cd geos
-Original Message-
From: [EMAIL PROTECTED] on behalf of Martin Davis
Sent: Fri 9/26/2008 11:47 AM
> Do you know how "inefficient" GCJ is? Maybe it's not that bad at
> all... As long as its garbage collector is efficient it could be
> similar performance to Java. AFAIU garbage collector
Martin,
> This seems like it might be building GEOS to be a bit too specific to
> its use in PostGIS, however. I think there's lots of people who want to
> use it in other environments.
Slightly off-topic - but have you been looking at how those evil C# people have
been interpreting JTS?
http
> Why not just use GCJ? It compiles Java to object code. That gives the
> best of both worlds.
Hmm I thought we tried that already and it didn't work nicely? Wasn't that
what all that embed java was about or am I mistaken? If it hasn't been tried,
then I guess that would be the path of leas
Mark,
> If I had a choice then it would be to spend the time re-engineering
> Martin's JTS concepts/ideas into an algorithmic form which is friendly
> to the language it is being written in, rather than trying to hack in
> pointer reference counting. Work with the language, not against it.
Sou
I apologize for being a bit long-winded here.
Recall I mentioned that Geometry.Union() does some short-circuit stuff
and then does the standard Overlay op stuff.
However GEOS Capi GeomUnion doesn't appear to use Geometry.Union() at all and
goes straight for the Overlay operation.
On closer insp
ion number refers to the whole repository
at once, the CVS revision numbers increment per-file.
P.
On Wed, Sep 17, 2008 at 7:10 PM, Obe, Regina <[EMAIL PROTECTED]> wrote:
> Ah okay that explains a lot why all these numbers are in the 1.1 - 1.5
> range. So I take it I can't completely
osed to the JTS release
version.
P.
On Wed, Sep 17, 2008 at 5:58 PM, Obe, Regina <[EMAIL PROTECTED]> wrote:
> Okay so I guess we still need the elevation thing. Can we get rid of the
> checkwrong thing or is that still needed for 64-bit systems?
>
> On a slightly (I like things
ignore the Last Port comment that appears in
each class file which seem to be grossly out of date?
Thanks,
Regina
-Original Message-
From: [EMAIL PROTECTED] on behalf of Obe, Regina
Sent: Wed 9/17/2008 8:58 PM
To: GEOS Development List
Subject: RE: [geos-devel] OverlayOp JTS port
Okay so I
vis <[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:
>>
>&
his method may not
be needed any more.
Obe, Regina wrote:
>
> I apologize for the barrage of questions. As far as I can tell the
> OverlayOp.cpp is vintage JTS 1.7 (which I think is same as the JTS 1.9
> for this class)
>
> except it has the additional calls of
>
> c
n trying to improve
GEOS robustness. This is probably where the checkObviouslyWrongResult
came from. After this was done, JTS caught up - so this method may not
be needed any more.
Obe, Regina wrote:
>
> I apologize for the barrage of questions. As far as I can tell the
> Overlay
n't realize
Union actually works with those, but then I never tried it with 3d.
So I'm a little puzzled why these 2 extra function calls since I always thought
GEOS was at best on par with JTS?
Thanks,
Regina
-Original Message-
From: [EMAIL PROTECTED] on behalf of Obe, Regina
S
I'm still trying to understand the geos codebase and just C and C++ in
general, so forgive me if my questions seem naive.
In the geos_c.cpp (both trunk and 3.0) - starting at line 92
I see this
using geos::operation::overlay::OverlayOp;
using geos::operation::overlay::overlayOp;
I assume the on
Mateusz,
> Are you asking about the redundant "using" directive or about use of
> "using" directive in general?
Mostly the redundant using. I wasn't sure if there was some mysterious
class I was missing. I assume using in C++ plays the same role as it
does in C#.
Thanks,
Regina
I'm looking at the operation.overlay.OverlayOp in geos trunk
In the header it says
Last port: operation/overlay/OverlayOp.java rev. 1.23
But I don't believe this to be right since when I compare the
computeOverlay methods
against 1.2 and 1.3 versions of JTS codebase, it has an additional
EdgeNodi
I accidentally sent to the old address. Sorry about that.
---
I'm looking at the operation.overlay.OverlayOp in geos trunk
In the header it says
Last port: operation/overlay/OverlayOp.java rev. 1.23
But I don't believe this to be right since wh
90 matches
Mail list logo
