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

[Havard Tveite]

Obe, Regina wrote:
> 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?

They do - at the data type level, anyway - that is why they
say that z and m values shall be ignored... ;-)

Here is the well-known text BNF for point (POINT, POINTZ, POINTM, POINTZM):
<point text representation> ::= POINT [ <z m> ] <point text>
<point text> ::= <empty set> | <left paren> <point> <right paren>
<point> ::= <x> <y> [ <z> ] [ <m> ]

You will find the [ <z m> ] for all the geometries.

But, I have not seen the final standard, just the FCD.

I think the level of support for >2D in SQL/MM Spatial is
very similar to the level of PostGIS support for > 2 dimensions.

> 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.

As long as PostGIS does not support >2D in our functions, I can
see no reason for not sticking to the SQL/MM Spatial specification.
When/If PostGIS goes 3D, I still think it would be sensible to call
the operations by another name to not break SQL/MM Spatial
compliance.
But, as you might remember, I also wanted PostGIS to use the ST_
prefix for SQL/MM Spatial functions only... ;-)

> 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 :).

According to the above, they might, since geometry datatypes for
XYZ, XYM and XYZM seem to be supported by SQL MM/Spatial.

Håvard

> 
> 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.
> _______________________________________________
> 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/