<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7652.24">
<TITLE>RE: [geos-devel] OverlayOp JTS port</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=2>The other thing I'm noticing is that the Geometry.union() methods are completely different between the Geos trunk and JTS (well 1.7 I'm looking at at the moment), but I haven't looked at older JTS code or 1.9 to<BR>
see if it matches with what it claims to be JTS 1.1 port.<BR>
<BR>
The Geos Geometry.Union() has a lot of short-circuit code in it that JTS<BR>
Geometry.union doesn't (but then that could just be a result of code shuffling)<BR>
<BR>
Am I safe in assuming that the whole Geometry.Union stuff is completely ignored<BR>
by Geos CAPI anyway so the point is moot as far as CAPI is concerned? Unless of course this short-circuit stuff actually works, then we should probably use it somehow. Based on my limited understanding of how C++ flows, I don't see how this would ever get called by CAPI.<BR>
<BR>
Thanks,<BR>
Regina<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: geos-devel-bounces@lists.osgeo.org on behalf of Martin Davis<BR>
Sent: Wed 9/17/2008 2:24 PM<BR>
To: GEOS Development List<BR>
Subject: Re: [geos-devel] OverlayOp JTS port<BR>
<BR>
The original plan for GEOS was that it would track JTS 100%. This was<BR>
to simplify porting new functionality as it is added to JTS. However,<BR>
at one point I think Sandro did some extra work on trying to improve<BR>
GEOS robustness. This is probably where the checkObviouslyWrongResult<BR>
came from. After this was done, JTS caught up - so this method may not<BR>
be needed any more.<BR>
<BR>
<BR>
<BR>
Obe, Regina wrote:<BR>
><BR>
> I apologize for the barrage of questions. As far as I can tell the<BR>
> OverlayOp.cpp is vintage JTS 1.7 (which I think is same as the JTS 1.9<BR>
> for this class)<BR>
><BR>
> except it has the additional calls of<BR>
><BR>
> checkObviouslyWrongResult() - which most of that code looks like it<BR>
> would never<BR>
> be called because of the #ifdefs except for the<BR>
><BR>
> assert(resultGeom);<BR>
> UNREFERENCED_PARAMETER(opCode); (have no clue what this does)<BR>
><BR>
> and also a<BR>
> elevationMatrix->elevate(resultGeom);<BR>
><BR>
> which looks like will get called since USE_ELEVATION_MATRIX 1.<BR>
><BR>
> Is the elevationMatrix designed to deal with 3d geometries? Didn't<BR>
> realize<BR>
> Union actually works with those, but then I never tried it with 3d.<BR>
><BR>
> So I'm a little puzzled why these 2 extra function calls since I<BR>
> always thought<BR>
> GEOS was at best on par with JTS?<BR>
><BR>
> Thanks,<BR>
> Regina<BR>
><BR>
> -----Original Message-----<BR>
> From: geos-devel-bounces@lists.osgeo.org on behalf of Obe, Regina<BR>
> Sent: Wed 9/17/2008 9:26 AM<BR>
> To: GEOS Development List<BR>
> Subject: [geos-devel] OverlayOp JTS port<BR>
><BR>
> I'm looking at the operation.overlay.OverlayOp in geos trunk<BR>
><BR>
> In the header it says<BR>
> Last port: operation/overlay/OverlayOp.java rev. 1.23<BR>
><BR>
> But I don't believe this to be right since when I compare the<BR>
> computeOverlay methods<BR>
> against 1.2 and 1.3 versions of JTS codebase, it has an additional<BR>
> EdgeNodingValidator check which wasn't introduced until later versions<BR>
> of JTS.<BR>
><BR>
> So I'm wondering is the OverlayOp.cpp a mix of JTS versions or is the<BR>
> comment above just plain wrong.<BR>
><BR>
> It also has a checkObviouslyWrongResult() check at the end of<BR>
> computerOverlay which I haven't figured out which version that was<BR>
> introduced in JTS (its not in 1.2,1.3, or 1.9). Is this a GEOS specific<BR>
> check that has no JTS equivalent?<BR>
><BR>
> Thanks,<BR>
> Regina<BR>
> -----------------------------------------<BR>
> The substance of this message, including any attachments, may be<BR>
> confidential, legally privileged and/or exempt from disclosure<BR>
> pursuant to Massachusetts law. It is intended<BR>
> solely for the addressee. If you received this in error, please<BR>
> contact the sender and delete the material from any computer.<BR>
><BR>
> _______________________________________________<BR>
> geos-devel mailing list<BR>
> geos-devel@lists.osgeo.org<BR>
> <A HREF="http://lists.osgeo.org/mailman/listinfo/geos-devel">http://lists.osgeo.org/mailman/listinfo/geos-devel</A><BR>
><BR>
><BR>
><BR>
> ------------------------------------------------------------------------<BR>
><BR>
> _______________________________________________<BR>
> geos-devel mailing list<BR>
> geos-devel@lists.osgeo.org<BR>
> <A HREF="http://lists.osgeo.org/mailman/listinfo/geos-devel">http://lists.osgeo.org/mailman/listinfo/geos-devel</A><BR>
<BR>
--<BR>
Martin Davis<BR>
Senior Technical Architect<BR>
Refractions Research, Inc.<BR>
(250) 383-3022<BR>
<BR>
_______________________________________________<BR>
geos-devel mailing list<BR>
geos-devel@lists.osgeo.org<BR>
<A HREF="http://lists.osgeo.org/mailman/listinfo/geos-devel">http://lists.osgeo.org/mailman/listinfo/geos-devel</A><BR>
<BR>
</FONT>
</P>
</BODY>
</HTML>