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

[Obe, Regina]

Håvard,
Ah okay.  Then I am a bit concerned.  So are you saying something like the below is legal in SQL/MM lingo?

SELECT ST_GeometryFromText('POINTZ(1 2 3)');

But PostGIS currently throws an error when you do the above and the above.
ERROR:  parse error - invalid geometry

I'm still confused where the old spec and the new MM spec intersect.  Like should

SELECT ST_AsText(ST_GeomFromEWKT('POINT(1 2 3)'));

be returning
POINTZ(1 2 3)

instead of 
POINT(1 2)

and why POINTZ throws an error for ST_GeomFromEWKT (though that doesn't claim to be SQL-MM compliant anyway), although works fine for
SELECT ST_AsEWKT(ST_GeometryFromText('POINTM(1 2 3)'))

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 10:04 AM
To: PostGIS Development Discussion
Subject: Re: [postgis-devel] Dropped DM (Time) dimension with intersections

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