[geos-devel] OverlayOp JTS port

Obe, Regina robe.dnd at cityofboston.gov
Wed Sep 17 23:29:47 EDT 2008 

Paul,

Okay - is this number CVS of Geos or CVS of JTS pull?  

I guess it doesn't really matter too much.  I'll assume JTS 1.71 when I'm looking at a file and compare against JTS 1.71 unless I notice its got mutant or upper stream code in it and then look up or down a version.  At least it gives me a starting point.

Most of this exercise was just to familiarize myself with how JTS code is translated to C++ since I have a much easier time understanding Java than C++.  I figured if I was looking at things that are supposed to be the same I would have an easier time understanding (e.g. when to use address or copy or whatever).  Then I accidentally stumbled across things that were obviously different like the short-circuit in GEOS Geometry.Union (and the fact its not even named the same e.g JTS is Geometry.union) and how if at all this even comes into play in CAPI (doesn't seem to). and if all that short-circuit stuff can be replaced with JTS 1.8+ SnapIfNeededOverlayOp.overlayOp(this, other, OverlayOp.UNION) (haven't figured out what that does).

Anyrate its been an educational and fun experience.  Its always exciting to look behind a black box and discover it doesn't quite work the way you assumed it did.

Thanks,
Regina





-----Original Message-----
From: geos-devel-bounces at lists.osgeo.org on behalf of Paul Ramsey
Sent: Wed 9/17/2008 11:00 PM
To: GEOS Development List
Subject: Re: [geos-devel] OverlayOp JTS port
 
Unlike SVN, where the revision number refers to the whole repository
at once, the CVS revision numbers increment per-file.

P.

On Wed, Sep 17, 2008 at 7:10 PM, Obe, Regina <robe.dnd at cityofboston.gov> wrote:
> Ah okay that explains a lot why all these numbers are in the 1.1 - 1.5
> range.  So I take it I can't completely trust the 1.71 since they don't all
> have the same revision number, though it seems about right from the classes
> I've looked at minus the obvious diversions from the path.
>
>
>
>
> -----Original Message-----
> From: geos-devel-bounces at lists.osgeo.org on behalf of Paul Ramsey
> Sent: Wed 9/17/2008 9:46 PM
> To: GEOS Development List
> Subject: Re: [geos-devel] OverlayOp JTS port
>
> No, I think you need to check more closely, as the value given there
> might be the actual CVS version string, as opposed to the JTS release
> version.
>
> P.
>
> On Wed, Sep 17, 2008 at 5:58 PM, Obe, Regina <robe.dnd at cityofboston.gov>
> wrote:
>> 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
>>
>>
>> _______________________________________________
>> 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
>
>
> _______________________________________________
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/geos-devel/attachments/20080917/d1cd0416/attachment-0001.html

More information about the geos-devel mailing list