Changes between Version 68 and Version 69 of WKTRaster/SpecificationWorking01

Timestamp:

12/16/09 13:25:52 (15 years ago)

Author:

pracine

Comment:

—

WKTRaster/SpecificationWorking01

@@ -203 +203 @@
 
  The only difference with ST_Box2D(raster) is that ST_Envelope(raster) returns a geometry, not a BOX2D.
- 
- There is also a ticket (#348) related to this function: http://trac.osgeo.org/postgis/ticket/348
+
+
+ '''Implementation details'''
+
+ This function should be implemented as a SQL or a PL/pgSQL function looking like: 'SELECT ST_geometry(ST_Box2D(rast))'
+
+ There is already a ST_raster_envelope() function but this has actually the behavior of the  ST_ConvexHull(raster, 'WITHNODATA') described below. There is also a ticket (#348) related to this function: http://trac.osgeo.org/postgis/ticket/348
 
 '''ST_ConvexHull(raster) -> polygon geometry''' - Returns the minimum convex geometry that encloses every significant pixel from the raster. 
@@ -210 +215 @@
  By default the resulting polygon TAKES the NODATA values into account. The resulting polygon enclose only pixels having a significant value (different than the NODATA value).
 
- A ST_ConvexHull(raster, 'WITHNODATA') variant SHOULD NOT TAKE the NODATA value into account. It generally returns a square or rectangle polygon that can be rotated or not depending on the rotation of the raster. If the raster is not rotated ST_ConvexHull(geometry, 'WITHNODATA') is (almost) equivalent to ST_Envelope(raster).
-
- This variant should replace the actual ST_raster_envelope() function which is wrongly named.
-
+ Variant 1: ST_ConvexHull(raster, 'WITHNODATA') SHOULD NOT TAKE the NODATA value into account. It generally returns a square or rectangle polygon that can be rotated or not depending on the rotation of the raster. If the raster is not rotated ST_ConvexHull(geometry, 'WITHNODATA') is (almost) equivalent to ST_Envelope(raster).
 
  '''Implementation details'''
@@ -219 +221 @@
  The first variant (taking NODATA values into account) ST_ConvexHull(raster) could be roughly implemented with a SQL or PL/pgSQL function looking like 'SELECT ST_ConvexHull(ST_Shape(raster))'. For sure computing only the external edge (without considering eventual holes like ST_Shape() does) should be faster. This imply writing the equivalent of a more simple version of ST_Shape.
 
- The second variant (not taking NODATA values into account) is 
+ The second variant (not taking NODATA values into account) is actually already implemented by the ST_raster_envelope() function which is wrongly named. There is also a ticket (#348) related to this function: http://trac.osgeo.org/postgis/ticket/348
 
 '''ST_Shape(raster) -> polygon geometry''' - Returns a geometry encomparsing every pixel having a significant value (different than the NODATA value).