[postgis-devel] Dropped DM (Time) dimension with intersections

[Obe, Regina]

Håvard,
I don't think 3D is supported in SQL/MM at all was my understanding. Do they even have a representation for 3D/4D?

So technically I suppose we can say we are in violation in many functions we claim are SQL/MM compliant.  Technically speaking a function that can return a 3D/4D geometry can not really be considered SQL/MM compliant, but to me that's not a terribly meaningful violation.  The debatability of the 3D answer does seem a bit of a concern to me but I'm not going to cry over it just yet.

Presumably people caring about SQL/MM compliancy will not be using 3D geometries in operations expecting their results to be flattened to 2D because SQL/MM doesn't have a representation for 3D (?). So that restriction seems more for ease of implementation of SQL/MM than anything else.  I presume most people caring about SQL/MM compliancy will be using 2D geometries and would never exercise the non-compliant nature of the functions. Though I could be wrong. So we are in compliance in spirit not verbatim :).

Thanks,
Regina

-----Original Message-----
From: postgis-devel-bounces at postgis.refractions.net [mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of Havard Tveite
Sent: Wednesday, October 08, 2008 6:00 AM
To: PostGIS Development Discussion
Subject: Re: [postgis-devel] Dropped DM (Time) dimension with intersections

According to the (FCD) version I have of SQL/MM Spatial, the
ST_ConvexHull shall ignore z/m values, and the z/m values shall
not be included in the ST_Points contained in the resulting
ST_Geometry (I guess this means that 2D geometry shall be
returned).

Citation from SQL/MM FCD (from 2005), ST_ConvexHull:
*************************************************************
c) If SELF.ST_Is3D() is equal to 1 (one), then:
i) The z coordinate values are not considered in the calculation.
ii) The ST_Point values contained in the returned ST_Geometry value do not include z
coordinate values.
d) If SELF.ST_IsMeasured() is equal to 1 (one), then:
i) The m coordinate values are not considered in the calculation.
ii) The ST_Point values contained in the returned ST_Geometry value do not include m
coordinate values.
*************************************************************

The same applies to the other operations that shall return
regions in space: ST_Buffer and ST_Envelope (with 3D
support, these should return volumes when 3D geometries are
supplied as input).
It also applies some other operations that return geometry
(at least ST_Boundary, ST_Intersection, ST_Union,
ST_Difference, ST_SymDifference, ST_MidPointRep, ST_Centroid
and ST_PointOnSurface).

So, the PostGIS answer is not according to SQL/MM Spatial (and
is wrong, anyway).  As long as PostGIS does not support more
than 2D for most(?) operations, and can not return higher
dimension regions, the SQL/MM behaviour seems reasonable.


Håvard

Chris Hodgson wrote:
> I think the answer is, nobody really knows, but it seemed to make as
> much sense as possible given the operation being requested. If it
> doesn't work for your use case then feel free to make a solid argument
> for why we should give a different result and provide a robust method to
> calculate it :-)
> 
> Chris
> 
> 
> Obe, Regina wrote:
>> Which begs the question - what exactly does this tell me?
>>
>> SELECT
>> ST_AsEWKT(ST_ConvexHull(ST_Collect(ST_GeomFromEWKT('LINESTRING(1 2 3,3
>> 4 5, 3 6 7)'), ST_MakePoint(0, 2, 0))));
>> Result
>> "POLYGON((0 2 0,3 6 7,3 4 5,1 2 3,0 2 0))"
>>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
> 

-- 
Håvard Tveite
Department of Mathematical Sciences and Technology, UMB
Drøbakveien 31, POBox 5003, N-1432 Ås, NORWAY
Phone: +47 64965483 Fax: +47 64965401 http://www.umb.no/imt/
_______________________________________________
postgis-devel mailing list
postgis-devel at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-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.