[postgis-users] EMPTY geometries

Thu Apr 10 14:47:37 PDT 2003

I'll throw in the 2 cents worth from my experience with JTS here...

I essentially chose solution B for JTS.  You can make empty geometries of all types.  When JTS needs to represent an empty geometry, it makes a GEOMETRYCOLLECTION EMPTY (the rationale here was that GeometryCollections have the least semantics associated with them of any of the Geometry types, which is the closest to the "no semantics" that should hold for empty Geometries).

If you can't support empty components of collections, I would suggest that you simply delete them from the collection automatically.  That changes the pointset represented by the Geometry in the least possible way.
E.g. MULTILINESTRING( (0 0, 1 1), EMPTY, (2 2, 3 3)) ==> MULTILINESTRING( (0 0, 1 1), (2 2, 3 3))

You might want to allow both SQL NULL *and* empty Geometries.  NULL implies "we don't what should be here", whereas the empty Geometry means "we ran some process and it resulted in an empty Geometry" (e.g. intersection)

Martin Davis, Senior Technical Architect
Vivid Solutions Inc.
Suite #1A-2328 Government Street   Victoria, B.C.   V8T 5G5
Phone: (250) 385 6040    Fax: (250) 385 6046
EMail: mbdavis at vividsolutions.com  Web: www.vividsolutions.com

> -----Original Message-----
> From: David Blasby [mailto:dblasby at refractions.net]
> Sent: Thursday, April 10, 2003 2:38 PM
> To: postgis-users at postgis.refractions.net
> Subject: [postgis-users] EMPTY geometries
> 
> 
> Paul and I have been looking at PostGIS conformance, and I've been 
> looking at empty geometries.
> 
> 1. The OGC SF SQL spec doesnt seem to deal with empty geometries - it 
> calls them "the empty set".  It appears that it would be fine with a 
> single "NULL" geometry.
> 
> 2. WKT is really loosy-goosey about EMPTY geometries.  All the base 
> types can be empty (POINT, LINESTRING, MULTIPOLYON, etc...), but also 
> components of the types can be EMPTY.  For example:
> MULTILINESTRING( EMPTY, (EMPTY, EMPTY, EMPTY) )
> represents two linestrings - an empty one, and one made up of 3 empty 
> points.
> 
> 3. WKB isnt as loosy-goosey as WKT, but fairly free formed.  
> You cannot 
> represent an EMPTY point in WKB.  You can have empty objects like 
> linestrings with 0 points, or multilinestrings with 0 linestrings, or 
> multilinestrings with empty linestrings inside.
> 
> Currently PostGIS does not allow empty geometries at all.  It 
> uses the 
> SQL-NULL to represent them.
> 
> 
> ----
> 
> I dont really see any advantage to supporting the nasty empty 
> geometries.  They dont really add anything, and the specification say
> that you cannot make empty geometries:
> 
> "The instantiable subclasses of Geometry defined in this 
> specification 
> are restricted to 0, 1 and twodimensional
> geometric objects that exist in two-dimensional coordinate space."
> 
> Empty geometries do not have a dimension.
> 
> Also, the diagram (Figure 2.1) says that objects like 
> LINESTRING have 2+ 
> points (not 0, or 2+). And MULTILINESTRING has 1+ linestrings in it.
> 
> But, in keeping with the spirit of the spec, I see two ways 
> of dealing 
> with this:
> 
> A. Simple one-empty geometry
> 
> Have a single empty geometry type.  Its WKT representation would be 
> "GEOMETRYCOLLECTION( EMPTY )" and its WKB representation would also
> be an empty geometrycollection.  Any WKT with an empty in it would be
> converted to this type:
> 
> LINESTRING( EMPTY) -> GEOMETRYCOLLECTION( EMPTY )
> LINESTRING(0 0, EMPTY, 1 1) -> GEOMETRYCOLLECTION( EMPTY )
> MULTILINESTRING( (0 0, 1 1), EMPTY) -> GEOMETRYCOLLECTION( EMPTY )
> 
> * NB: a valid geometry was thrown away in the last case.  We might
>        want this to return a MULTILINESTRING( (0 0, 1 1)), but that
>        would take a bit of time to fix with the parser.
> 
> Any GEOS function that returns an empty set would have its results
> represented with this.
> 
> difference(g,g) -> GEOMETRYCOLLECTION( EMPTY )
> intersection( disjoin geoms) -> GEOMETRYCOLLECTION( EMPTY )
> 
> The main problem with this is the loss of type information
> 
> 	LINESTRING( EMPTY) -> GEOMETRYCOLLECTION( EMPTY )
>      The type of the geometry has changed from LINESTRING to a GC.
>      This could cause problems with tables that have constraints
>      on them to ensure they have a homogeneous type.
>      This fixable by having the contraint on the table be:
> 	isnull(geom) || geometryType(geom) = 'LINESTRING' ||
>          isEmpty(geom)
> 
>      GeometryType( <empty geometry>) -> GEOMETRYCOLLECTION
> 
> A second problem is that the location of sub-geometries in MULTI* 
> geometries will change:
> 
> GeometryN(MULTILINESTRING( (0 0, 1 1), EMPTY, (2 2, 3 3)), 2)
> 	should be LINESTRING EMPTY, but in our implementation
>          it would either be an error, or LINESTRING (2 2, 3 3).
> 
> 
> B. Typed empty geometries
> 
> This involves adding 7 new types (cf. postgis.h)
> EMPTY_POINT
> EMPTY_MULTIPOINT
> EMPTY_LINESTRING
> EMPTY_MULTILINESTRING
> EMPTY_POLYGON
> EMPTY_MULTIPOLYGON
> EMPTY_GEOMETRYCOLLECTION
> 
> NB: EMPTY_POINT is not representable in WKB, so it would have
>      to be converted to an EMPTY_MULTIPOINT.
> 
> Internal GEOS functions would only create EMPTY_GEOMETRYCOLLECTION.
> 
> The only real advantage of this is that users can create empty 
> geometries of a known type (ie. POINT EMPTY is different from 
> LINESTRING 
> EMPTY).
> This isnt too much more work than the single-type version.
> 
> C. Typed empty geometries with actual empty sub-types
> 
> This is very much like the WKB system.
> 
> Make geometries like LINESTRING valid with 0 points (representing 
> "LINESTRING EMPTY").  Make MULTI* valid with 0 sub-objects.
> Make an EMPTYPOINT type.
> 
> This means we're fully able to represent all the geometries except 
> screwy things like "LINESTRING( EMPTY, 1 2, EMPTY, 3 3)".
> 
> 
> 
> In terms of work, "A" is faily simple, "B" is about 3* as 
> much work, and 
>   "C" could take quite a while to ensure everything is 0-point and 
> 0-object aware.
> 
> In terms of conformance, "A" seems like its all we need.  The 
> spec looks 
> like it only requires some type of "empty set" geometry.  The 
> other two 
> methods are just there to be nice for the WKT and WKB specification. 
> I'm loath to mess up to code to allow for empty objects that 
> people will 
> probably never use.
> 
> What do you think?  Anyone have any different impressions of the 
> specification?  Anyone have any use for the funnier empty geometries?
> 
> dave
> 	
> 
> 
> 
> 
> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
> 