[postgis-devel] Re: NULL geometries

[Carl Anderson]

strk wrote:
> On Mon, Jun 07, 2004 at 11:53:03AM -0400, Carl Anderson wrote:
> 
>>strk wrote:
>>
>>
>>>Carl, you were right, it was the error function ....
>>>I've fixed it. Now you get ERRORs instead of traps.
>>>
>>>Also, I've unleashed the parser to accept miXeD case.
>>>
>>>A rimaning issue is about wheter to accept (MULTI)POINT(),
>>>(MULTI)LINESTRING(), (MULTI)POLYGON(), GEOMETRYCOLLECTION()
>>>as empty geometries... I think that would be nice, are there
>>>comments ?
>>>
>>
>>I am against it becuase it would tend to create in users minds the 
>>concept of a finer grain of null geometry
>>
>>sort of a null point vs a null polygon vs ...
>>when really there exists only a null geometry super class
>>
> 
> 
> Currently postgis supports (geometry and lwgeom):
> 	POINT(EMPTY)
> 	MULTIPOINT(EMPTY)
> 	LINESTRING(EMPTY)
> 	MULTILINESTRING(EMPTY)
> 	POLYGON(EMPTY)
> 	MULTIPOLYGON(EMPTY)
> 	GEOMETRYCOLLECTION(EMPTY)
> 
> Do you think it should drop all but last form support ?
> 
> Another note: table constraints added by AddGeometryColumn never
> allow the NULL geometry to be inserted, as the check goes:
> 
>   ((geometrytype(the_geom) = '<type>'::text) OR (the_geom IS NULL))
> 
> Maybe we should add an isnullgeom(geometry) returning true for
> NULL and GEOMETRYCOLLECTION(EMPTY).
> 
> comments ?
> 
> --strk;
> 
> 

Reading the SFSQL 1.0 spec
     postgis is required to accept
       'POINT()', 'LINESTRING()',  etc

But I don't see a requirement that it has to be stored as such

looking at 3.2.10.2 Language Constructs
   IsEmpty(g geometry): Integer
      The return type is Integer, with a return value of 1 for TRUE,
      0 for FALSE, and –1 for UNKNOWN corresponding to a function
      invocation on NULL arguments.


But I think in the bigger picture you may tend to outsmart the statement 
parser/planner.


-- 
Carl Anderson
GIS Manager, Fulton County E&CD
404.730.8026
carl.anderson at co.fulton.ga.us