[geos-devel] OverlayOp JTS port

[Obe, Regina]

Okay I did a quick union run of a 3 d geometry in PostGIS and it
apparently does do something with the z index

SELECT ST_AsEWKT(ST_Union(ST_MakePoint(x,y,z)))
FROM generate_series(1,5) x
	CROSS JOIN generate_series(2,10) y
	CROSS JOIN generate_series(1,10) z;

yields
MULTIPOINT(1 2 9.001953125,1 3 9.001953125,1 4 9.001953125,1 5
9.001953125,1 6 9.001953125,1 7 9.001953125,1 8 9.001953125,1 9
9.001953125,1 10 9.001953125,2 2 9.001953125,2 3 9.001953125,2 4
9.001953125,2 5 9.001953125,2 6 9.001953125,2 7 9.001953125,2 8
9.001953125,2 9 9.001953125,2 10 9.001953125,3 2 9.001953125,3 3
9.001953125,3 4 9.001953125,3 5 9.001953125,3 6 9.001953125,3 7
9.001953125,3 8 9.001953125,3 9 9.001953125,3 10 9.001953125,4 2
9.001953125,4 3 9.001953125,4 4 9.001953125,4 5 9.001953125,4 6
9.001953125,4 7 9.001953125,4 8 9.001953125,4 9 9.001953125,4 10
9.001953125,5 2 9.001953125,5 3 9.001953125,5 4 9.001953125,5 5
9.001953125,5 6 9.001953125,5 7 9.001953125,5 8 9.001953125,5 9
9.001953125,5 10 9.001953125)

Running the same exercise in OpenJump and looking at the output of GML,
WKT, CL I don't get a Z-axis.

I can't tell if its just that the z is not supported in those formats or
if its just because in JTS the z axis is thrown out.  Looking at the JTS
code, I have no reason to believe its doing anything with z.

I presume the GEOS elevationMatrix->elevate(resultGeom) is responsible
for this.

The question I have is - isn't this hmm wrong - I suppose we can say its
fuzzily right.

Thanks,
Regina



-----Original Message-----
From: geos-devel-bounces at lists.osgeo.org
[mailto:geos-devel-bounces at lists.osgeo.org] 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.  However, 
at one point I think Sandro did some extra work on 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
> 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
>
> checkObviouslyWrongResult() - which most of that code looks like it 
> would never
> be called because of the #ifdefs except for the 
>
> assert(resultGeom);
> UNREFERENCED_PARAMETER(opCode); (have no clue what this does)
>
> and also a
> elevationMatrix->elevate(resultGeom);
>
> which looks like will get called since USE_ELEVATION_MATRIX 1.
>
> Is the elevationMatrix designed to deal with 3d geometries?  Didn'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: geos-devel-bounces at lists.osgeo.org on behalf of Obe, Regina
> Sent: Wed 9/17/2008 9:26 AM
> To: GEOS Development List
> Subject: [geos-devel] OverlayOp JTS port
>
> 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
> EdgeNodingValidator check which wasn't introduced until later versions
> of JTS.
>
> So I'm wondering is the OverlayOp.cpp a mix of JTS versions or is the
> comment above just plain wrong.
>
> It also has a checkObviouslyWrongResult() check at the end of
> computerOverlay which I haven't figured out which version that was
> introduced in JTS (its not in 1.2,1.3, or 1.9).  Is this a GEOS
specific
> check that has no JTS equivalent?
>
> Thanks,
> Regina
> -----------------------------------------
> The substance of this message, including any attachments, may be
> confidential, legally privileged and/or exempt from disclosure
> pursuant to Massachusetts 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 at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/geos-devel
>
>
>
>
------------------------------------------------------------------------
>
> _______________________________________________
> geos-devel mailing list
> geos-devel at 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 at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel