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-boun...@lists.osgeo.org
[mailto:geos-devel-boun...@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@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@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel
_______________________________________________
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel
