[geos-devel] OverlayOp JTS port

Martin Davis mbdavis at refractions.net
Wed Sep 17 19:09:11 EDT 2008


Not so much pure - I just like things that I can understand  8^)

Paul Ramsey wrote:
> 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
>>
>>     
> _______________________________________________
> 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



More information about the geos-devel mailing list