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

Havard Tveite havard.tveite at umb.no
Thu Oct 9 00:12:58 PDT 2008


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

OGC Simple Feature Access SQL 1.2 includes Z (and M). I guess
it has been coordinated with the latest SQL/MM, since both
arrived in 2006.

1.2.0 OpenGIS Implementation Specification for Geographic information - Simple feature access - Part 2: SQL option:
<URL: http://portal.opengeospatial.org/files/?artifact_id=18242 >

Håvard

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



More information about the postgis-devel mailing list