[geos-devel] OverlayOp JTS port

Paul Ramsey pramsey at cleverelephant.ca
Wed Sep 17 23:00:32 EDT 2008 

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
>

More information about the geos-devel mailing list