[postgis-devel] POINT EMPTY in WKB

Paul Ramsey pramsey at opengeo.org
Mon Dec 6 13:25:15 PST 2010


In the new parser we do. MULTIPOINT EMPTY is legal, MULTIPOINT(EMPTY) is not.

P.

On Mon, Dec 6, 2010 at 1:22 PM, Paragon Corporation <lr at pcorp.us> wrote:
>  Though they seem to maintain the input display regardless.
>
> What I the difference between these two geometries?
>
>  SELECT Geometry::STGeomFromText('MULTIPOINT(EMPTY)',0).STAsText();
>
> Yields:  MULTIPOINT (EMPTY)
>
>   SELECT Geometry::STGeomFromText('MULTIPOINT EMPTY',0).STAsText();
>
> Yields: MULTIPOINT EMPTY
>
> Do we make a distinction between those?
>
>
>
>
> -----Original Message-----
> From: Paragon Corporation [mailto:lr at pcorp.us]
> Sent: Monday, December 06, 2010 4:09 PM
> To: 'PostGIS Development Discussion'
> Subject: RE: [postgis-devel] POINT EMPTY in WKB
>
> On my SQL Server 2008 the below
>
>  SELECT Geometry::STGeomFromText('POINT EMPTY',0).STAsText();
>
>
> Yields:
> POINT EMPTY
>
> Though I don't have the SQL server 2011 installed so who knows what that
> returns.  It sounds like in next release they've got a pretty beefed up
> curved support.  Even geodetic curved support and got rid of their
> hemisphere restriction.
>
> And
>
>  SELECT Geometry::STGeomFromText('POINT(EMPTY)',0).STAsText();
>
> Throws an error
>
> A .NET Framework error occurred during execution of user-defined routine or
> aggregate "geometry":
> System.FormatException: 24141: A number is expected at position 11 of the
> input. The input has EMPTY.
> System.FormatException:
>   at Microsoft.SqlServer.Types.OpenGisWktReader.RecognizeDouble()
>   at Microsoft.SqlServer.Types.OpenGisWktReader.ParsePointText(Boolean
> parseParentheses)
>   at Microsoft.SqlServer.Types.OpenGisWktReader.ParseTaggedText(OpenGisType
> type)
>   at Microsoft.SqlServer.Types.OpenGisWktReader.Read(OpenGisType type,
> Int32 srid)
>   at Microsoft.SqlServer.Types.SqlGeometry.GeometryFromText(OpenGisType
> type, SqlChars text, Int32 srid) .
>
> But I'm not running R2 version I don't think:
>
> Microsoft SQL Server 2008 (RTM) - 10.0.1600.22 (X64)   Jul  9 2008 14:17:44
> Copyright (c) 1988-2008 Microsoft Corporation  Standard Edition (64-bit) on
> Windows NT 5.2 <X64> (Build 3790: Service Pack 2)
>
>
> -----Original Message-----
> From: postgis-devel-bounces at postgis.refractions.net
> [mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of Paul
> Ramsey
> Sent: Monday, December 06, 2010 4:00 PM
> To: PostGIS Development Discussion
> Subject: Re: [postgis-devel] POINT EMPTY in WKB
>
> It's just POINT EMPTY. Everything else has a representation. In fact, I
> think Mats checked for me and SQLServer uses the same semantic as I am for
> empties in WKB, npoints=0 or ngeoms=0 or nrings=0 depending on the type
> being represented.
>
> And I think for POINT EMPTY they transform to GEOMETRYCOLLECTION EMPTY.
> (which is what we do now, see
>
>  SELECT AsText('POINT EMPTY'::geometry);
>
> P.
>
> On Mon, Dec 6, 2010 at 12:48 PM, Paragon Corporation <lr at pcorp.us> wrote:
>>
>>
>>> A final possibility would be to hack POINT EMPTY into WKB, as
>>> something like POINT(nan nan nan) or POINT(inf inf inf) or POINT(-0
>>> -0 -0). There would be a danger there in platforms that have
>>> different interpretations of what nan, inf or -0 are in binary.
>>
>> I the only issue with POINT EMPTY or ..anyspecifictype EMPTY
>>
>> I'm a bit bothered about the dump issue you describe -- not being able
>> to restore exactly what you thought you had.
>>
>> Thanks,
>> Regina
>>
>>
>>
>> _______________________________________________
>> 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
>
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>



More information about the postgis-devel mailing list