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.<div>
<br></div><div>David<br><br><div class="gmail_quote">On Wed, Jan 14, 2009 at 12:11 PM, Chris Hodgson <span dir="ltr"><<a href="mailto:chodgson@refractions.net">chodgson@refractions.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
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.<br>
<br>
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.<br>
<br>
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.<br>
<font color="#888888">
<br>
Chris</font><div><div></div><div class="Wj3C7c"><br>
<br>
Obe, Regina wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Well from my observation it looks like most of those Ops functions (not<br>
sure about Union and Intersection) -- first do a 2D operation and then<br>
do some sort of apply the Z back on. So the Z is never considered in<br>
the basic operation -- thus the cause of a lot of the goofiness.<br>
<br>
Take this example. It seems clear to me that these polygon's are not<br>
within each other so it should be a multipolygon not a Polygon with a<br>
hole. One lies above the other.<br>
<br>
SELECT ST_AsEWKT(ST_BuildArea('MULTILINESTRING((0 0 1,20 0 1,20 20 1,0<br>
20 1,0 0 1),(10 10 2,10 11 2,11 11 2,11 10 2,10 10 2))'))<br>
<br>
"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<br>
11 2,10 10 2))"<br>
<br>
<br>
<br>
<br>
<br>
-----Original Message-----<br>
From: <a href="mailto:geos-devel-bounces@lists.osgeo.org" target="_blank">geos-devel-bounces@lists.osgeo.org</a><br>
[mailto:<a href="mailto:geos-devel-bounces@lists.osgeo.org" target="_blank">geos-devel-bounces@lists.osgeo.org</a>] On Behalf Of strk<br>
Sent: Wednesday, January 14, 2009 4:04 AM<br>
To: GEOS Development List<br>
Subject: Re: 3D operations (Re: [geos-devel] C API coordinate<br>
sequencedimensions)<br>
<br>
On Wed, Jan 14, 2009 at 07:54:21AM +0000, Mark Cave-Ayland wrote:<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Can anyone with more experience with BuildArea (like Martin!) comment<br>
<br>
</blockquote>
on<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
whether this is a GEOS bug or simply a problem with behaviour > 2<br>
dimensions being undefined?<br>
<br>
</blockquote>
<br>
JTS didn't support 3d when I added it to GEOS, so can't really<br>
serve as a source of information. The 3d task was added driven by<br>
customer needs, so the only working and tested functions was the one<br>
the customer needed. If I recall correctly it was mainly Intersection<br>
and probably Union.<br>
<br>
Since other functions are based on the former, there may be side-effects<br>
you wouldn't care about if you aren't using 3d features.<br>
<br>
Paul draw the specs about expected behaviour. Dunno if there's a doc<br>
around and I likely lost mine (Oops).<br>
<br>
--strk; <br>
Free GIS & Flash consultant/developer () ASCII Ribbon Campaign<br>
<a href="http://foo.keybit.net/~strk/services.html" target="_blank">http://foo.keybit.net/~strk/services.html</a> /\ Keep it simple! _______________________________________________<br>
geos-devel mailing list<br>
<a href="mailto:geos-devel@lists.osgeo.org" target="_blank">geos-devel@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/geos-devel" target="_blank">http://lists.osgeo.org/mailman/listinfo/geos-devel</a><br>
-----------------------------------------<br>
The substance of this message, including any attachments, may be<br>
confidential, legally privileged and/or exempt from disclosure<br>
pursuant to Massachusetts law. It is intended<br>
solely for the addressee. If you received this in error, please<br>
contact the sender and delete the material from any computer.<br>
_______________________________________________<br>
geos-devel mailing list<br>
<a href="mailto:geos-devel@lists.osgeo.org" target="_blank">geos-devel@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/geos-devel" target="_blank">http://lists.osgeo.org/mailman/listinfo/geos-devel</a><br>
<br>
</blockquote>
<br>
_______________________________________________<br>
geos-devel mailing list<br>
<a href="mailto:geos-devel@lists.osgeo.org" target="_blank">geos-devel@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/geos-devel" target="_blank">http://lists.osgeo.org/mailman/listinfo/geos-devel</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>************************************<br>David William Bitner<br>
</div>