Changes between Version 40 and Version 41 of DevWikiEmptyGeometry

Timestamp:

Jan 13, 2012, 3:53:31 PM (12 years ago)

Author:

pramsey

Comment:

—

DevWikiEmptyGeometry

@@ -1 +1 @@
 = EMPTY GEOMETRY Handling =
 
-The semantics of NULL are well defined for us already in SQL standards. However, in the world of Geometry / Geography we have another entity which is not quite NULL nor quite fully defined: the empty geometry. Empty geometries can be created with things like intersection calls that have have no intersection, e.g. ST_Intersect('POINT(0 0)', 'POINT(1 1)') == POINT EMPTY. So, in the presence of empty, how should functions behave?
+The semantics of NULL are well defined for us already in SQL standards. However, in the world of Geometry / Geography we have another entity which is not quite NULL nor quite fully defined: the empty geometry. Empty geometries can be created with things like intersection calls that have have no intersection, e.g. ST_Intersection('POINT(0 0)', 'POINT(1 1)') == POINT EMPTY. So, in the presence of empty, how should functions behave?
 
 Ideally ''GEOMETRY EMPTY'' should behave more like 'zero' (0) than NULL - it is an expected, valid result of a successful, valid operation. In other words, dealing with ''EMPTY'' should require as little "special case" handling as possible in logical expressions making use of multiple geometry operations and/or comparisons. Maintaining compatibility with other spatial databases is probably valuable in its own right, and also because they have probably already done some thinking around these issues.
@@ -36 +36 @@
  * ST_Disjoint(empty, empty) == TRUE (SQL Server says True)
  * ST_Disjoint(geometry, empty) == TRUE (SQL Server says True)
+ * ST_Equals(empty, empty) == TRUE
  * ST_IsSimple(empty) == TRUE
  * ST_IsValid(empty) == TRUE