Changes between Version 97 and Version 98 of WKTRaster/SpecificationWorking01

Timestamp:

Jan 5, 2010, 1:17:47 PM (14 years ago)

Author:

pracine

Comment:

—

WKTRaster/SpecificationWorking01

@@ -239 +239 @@
  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
-
-[[Image(WKTRasterEnvelopeAndConvexHull.gif)]]
+ There is already a ST_raster_envelope() function but this has actually the behavior of the ST_ConvexHull(raster) described below. There is also a ticket (#348) related to this function: http://trac.osgeo.org/postgis/ticket/348
+
+[[Image(WKTRasterEnvelopeConvexHullAndShape.gif)]]
 
 '''ST_ConvexHull(raster) -> polygon geometry''' - Returns the minimum convex geometry that encloses every significant pixel from the raster. 
 
- 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).
-
- 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'''
-
- The first variant (taking NODATA values into account) ST_ConvexHull(raster) could be roughly implemented as 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 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
+ The resulting polygon DOES NOT TAKE the NODATA values into account. The resulting polygon enclose every pixel, even those containing NODATA values. It can be rotated or not depending on the rotation of the raster. If the raster is not rotated ST_ConvexHull(geometry) is (almost) equivalent to ST_Envelope(raster).
+
+ '''Implementation details'''
+
+ This function 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).
 
- This polygon geometry might contain holes if some internal areas of the raster contain pixels with NODATA values. By opposition ST_ConvexHull(raster) never contains holes.
+ This polygon geometry might contain holes if some internal areas of the raster contain pixels with NODATA values.
 
  '''Implementation details'''
 
  This function could be roughly implemented as a SQL function looking like 'SELECT ST_Collect((ST_AsPolygon(raster)).geom)'. For sure a more specialised version could be faster than ST_AsPolygon.
-
-[[Image(WKTRasterShape.gif)]]
 
 '''ST_AsPolygon(raster) -> geomval set''' - Returns a set of "geomval" value, one for each contiguous group of pixel sharing the same value.
@@ -317 +311 @@
  Variant 2: ST_Intersects(raster, raster) -> boolean
 
- This function permform a full intersection test and proceed in three steps to determine if the raster intersects with the geometry:
-
- 1) It first checks if the bounding box of the raster intersects with the bounding box of the geometry using the && operator. This test if very quick.
-
- 2) If the first test returns TRUE, it checks if the geometry returned by ST_ConvexHull(raster, 'WITHNODATA') intersects with the geometry. This test is slower since it might involve the geometry shape.
-
- 3) If the second test returns TRUE, it checks if the geometry returned by ST_Shape(raster) intersects with the geometry. This test is slower since it involve the computation of the raster shape and it might involve the geometry shape.
+ This function permform a full intersection test and proceed in two steps to determine if the raster intersects with the geometry:
+
+ 1) First, it checks if the geometry returned by ST_ConvexHull(raster) intersects with the geometry.
+
+ 2) If the first test returns TRUE, it checks if the geometry returned by ST_Shape(raster) intersects with the geometry. This test is slower since it involve the computation of the raster shape and it might involve the geometry shape.
 
  Variant 2 proceeds in a very similar way except that convex hulls of both rasters are computed and compared in step 2) and both shape of raster are computed and compared in step 3).
@@ -333 +325 @@
  If you want to limit the intersection test to the second condition you can write:
 
-  ST_Intersects(ST_ConvexHull(raster, 'WITHNODATA'), geometry)
+  ST_Intersects(ST_ConvexHull(raster), geometry)
 
  '''Implementation details'''
@@ -365 +357 @@
  If you only want to compute the intersection between the convex hull of the raster without polygonising it to group of contiguous pixels sharing a common value, do:
 
-  ST_Intersection(ST_ConvexHull(raster, 'WITHNODATA'), geometry)
+  ST_Intersection(ST_ConvexHull(raster), geometry)
 
  If you only want to compute the intersection between the shape of the raster without polygonising it to group of contiguous pixels sharing a common value, do: