[geos-devel] OverlayOp JTS port

Wed Sep 17 18:36:18 EDT 2008

Z-processing was added under contract to the Metropolitan Airport
Commission, some years ago, so that intersections (in particular)
would retain interpolated Z-values that "made sense".  This was
GEOS-only.

Sandro also did a good deal of robustness work in GEOS only, which
dealt with failures showing up in 64-bit systems but not in 32-bit
systems. Mostly these were in the form of perturbation hacks, rounding
things up until they worked, and so on. Martin is (mostly) too pure to
result to these kinds of things :)

P.

On Wed, Sep 17, 2008 at 2:33 PM, Martin Davis <mbdavis at refractions.net> 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:
>>
>> 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
>