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

Wed Oct 8 08:22:42 PDT 2008

Correct, PostGIS currently throws an error when parsing POINTZ or POINT 
Z (as per OGC specs).

Back in June when we talked about this, PaulR mentioned he would attempt 
to expand the lex/yacc book for 1.4

http://postgis.refractions.net/pipermail/postgis-devel/2008-June/003163.html

Cheers,
Kevin

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