3D operations (Re: [geos-devel] C API coordinate sequencedimensions)

[David William Bitner]

Just to add $.02 to this discussion, the use case that led to the 2.5D
intersection capabilities was for the analysis of flight tracks around an
airport.  A very common analysis is what is called a "gate analysis" where a
2D line (the gate) is drawn and the 2D intersection between the gate and the
flight tracks that go over that line is calculated.  Carrying the
Z coordinate through allows for very useful statistics to be calculated on
the result.  This allows to answer questions such as what was the minimum,
maximum, and average altitude of all aircraft that went through the gate.
David

On Wed, Jan 14, 2009 at 12:11 PM, Chris Hodgson <chodgson at refractions.net>wrote:

> AFAIK, the "3-d" functions were never truly 3-d, more what is sometimes
> called 2.5-d. That is, all of the operations return the same result, in 2-d,
> that they would return if the inputs had been 2-d - but then some heuristics
> are used to come up with a reasonable value for the 3rd coordinate.
>
> So in your example, Regina, the two polygons DO intersect in 2-d. In 2.5-d,
> there is no way for something to be "above" something else. Think of the z
> value as the height of the line - not the elevation, but think of the line
> as having a height, like a ribbon on it's side.
>
> These 2.5-d operations are very useful, particularly the cases which have
> well-defined results. They are also not compatible with true 3-d operations,
> but since GEOS doesn't support volumes, (polyhedrons and spheres and the
> like) true 3-d operations aren't something I think we need to worry about
> yet.
>
> Chris
>
>
> Obe, Regina wrote:
>
>> Well from my observation it looks like most of those Ops functions (not
>> sure about Union and Intersection) -- first do a 2D operation and then
>> do some sort of apply the Z back on.  So the Z is never considered in
>> the basic operation -- thus the cause of a lot of the goofiness.
>>
>>  Take this example.  It seems clear to me that these polygon's are not
>> within each other so it should be a multipolygon not a Polygon with a
>> hole. One lies above the other.
>>
>> SELECT ST_AsEWKT(ST_BuildArea('MULTILINESTRING((0 0 1,20 0 1,20 20 1,0
>> 20 1,0 0 1),(10 10 2,10 11 2,11 11 2,11 10 2,10 10 2))'))
>>
>> "POLYGON((0 0 1,0 20 1,20 20 1,20 0 1,0 0 1),(10 10 2,11 10 2,11 11 2,10
>> 11 2,10 10 2))"
>>
>>
>>
>>
>>
>> -----Original Message-----
>> From: geos-devel-bounces at lists.osgeo.org
>> [mailto:geos-devel-bounces at lists.osgeo.org] On Behalf Of strk
>> Sent: Wednesday, January 14, 2009 4:04 AM
>> To: GEOS Development List
>> Subject: Re: 3D operations (Re: [geos-devel] C API coordinate
>> sequencedimensions)
>>
>> On Wed, Jan 14, 2009 at 07:54:21AM +0000, Mark Cave-Ayland wrote:
>>
>>
>>
>>> Can anyone with more experience with BuildArea (like Martin!) comment
>>>
>>>
>> on
>>
>>
>>> whether this is a GEOS bug or simply a problem with behaviour > 2
>>> dimensions being undefined?
>>>
>>>
>>
>> JTS didn't support 3d when I added it to GEOS, so can't really
>> serve as a source of information. The 3d task was added driven by
>> customer needs, so the only working and tested functions was the one
>> the customer needed. If I recall correctly it was mainly Intersection
>> and probably Union.
>>
>> Since other functions are based on the former, there may be side-effects
>> you wouldn't care about if you aren't using 3d features.
>>
>> Paul draw the specs about expected behaviour. Dunno if there's a doc
>> around and I likely lost mine (Oops).
>>
>> --strk;
>>  Free GIS & Flash consultant/developer      ()  ASCII Ribbon Campaign
>>  http://foo.keybit.net/~strk/services.html  /\  Keep it simple!
>> _______________________________________________
>> geos-devel mailing list
>> geos-devel at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/geos-devel
>> -----------------------------------------
>> 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
>



-- 
************************************
David William Bitner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/geos-devel/attachments/20090114/df811fb3/attachment.html