Changes between Version 40 and Version 41 of DevWikiEmptyGeometry
- Timestamp:
- 01/13/12 15:53:31 (13 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
DevWikiEmptyGeometry
v40 v41 1 1 = EMPTY GEOMETRY Handling = 2 2 3 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?3 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? 4 4 5 5 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) 37 37 * ST_Disjoint(geometry, empty) == TRUE (SQL Server says True) 38 * ST_Equals(empty, empty) == TRUE 38 39 * ST_IsSimple(empty) == TRUE 39 40 * ST_IsValid(empty) == TRUE