[geos-devel] OverlayOp JTS port
Obe, Regina
robe.dnd at cityofboston.gov
Wed Sep 17 20:58:17 EDT 2008
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 I can understand note :)), can we update the header about the Last Ported. Its driving me a bit crazy that the last ported note doesn't actually
seem to match the vintage of the JTS code (i suspect there are toher classes where this is the case) and I'm having to verify that. That seems like an important thing to have handy if we are going to be migrating new changes from JTS into GEOS.
Thanks,
Regina
-----Original Message-----
From: geos-devel-bounces at lists.osgeo.org on behalf of Martin Davis
Sent: Wed 9/17/2008 7:09 PM
To: GEOS Development List
Subject: Re: [geos-devel] OverlayOp JTS port
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
_______________________________________________
geos-devel mailing list
geos-devel at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/geos-devel/attachments/20080917/e0d70152/attachment-0001.html
More information about the geos-devel
mailing list