Context Navigation

Changes between Version 119 and Version 120 of WKTRaster/SpecificationWorking01

Timestamp:: Apr 7, 2010, 11:20:21 AM (14 years ago)
Author:: pracine
Comment:: —

Legend:

: Unmodified
: Added
: Removed
: Modified

WKTRaster/SpecificationWorking01

-              v119
+              v120
 == '''Objective 0.1.6e - Being able to intersect vector and raster to produce vector.''' ==
 List of PostGIS functions similar or related to ST_GetBBox(), ST_Envelope() and ST_Shape():
+List of PostGIS functions similar or related to ST_GetBBox(), ST_Envelope() and ST_Polygon():
 [http://postgis.refractions.net/documentation/manual-1.4/ST_Boundary.html ST_Boundary(geometry)] (not really - always return a geometry a dimension lower - i.e. the boundary of a polygon is a polyline.)
 …
  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, integer) -> polygon geometry''' - Returns a geometry encomparsing every pixel having a significant value (different than the NODATA value) for the provided band.
+'''ST_Polygon(raster, integer) -> polygon geometry''' - Returns a geometry encomparsing every pixel having a significant value (different than the NODATA value) for the provided band.
  This polygon geometry might contain holes if some internal areas of the raster contain pixels with NODATA values.
  Variant 1: ST_Shape(raster) -> polygon geometry -- default to band # 1
+ Variant 1: ST_Polygon(raster) -> polygon geometry -- default to band # 1
  '''Implementation details'''
 …
  Could also be named ST_Outline().
  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.
 '''ST_AsPolygon(raster, integer) -> geomval set''' - Returns a set of "geomval" value, one for each group of pixel sharing the same value for the provided band.
+ This function could be roughly implemented as a SQL function looking like 'SELECT ST_Collect((ST_DumpAsPolygons(raster)).geom)'. For sure a more specialised version could be faster than ST_AsPolygon.
+'''ST_DumpAsPolygons(raster, integer) -> geomval set''' - Returns a set of "geomval" value, one for each group of pixel sharing the same value for the provided band.
  This is a set-returning function (SRF). A "geomval" value is a complex type composed of a polygon geometry (one for each group of pixel sharing the same value) and the value associated with this geometry. These values are always returned as a value of type double precision. The shape of each polygon follow pixels edges.
+ Variant 1: ST_AsPolygon(raster) -> geomval set -- default to band # 1
+ Variant 2: ST_AsPolygon(raster, integer, 'CONTIGUOUS')[[BR]] -- the second parameter is the raster band number
+ Variant 3: ST_AsPolygon(raster, 'CONTIGUOUS') -- default to band # 1
+ This function should be used with precaution on raster with float pixel type as it could return one "geomval" (or polygon) per pixel. This kind of raster should be reclassified (using the planned ST_Reclassify(raster,...) function) before using ST_AsPolygon().
+ Variant 2 & 3 splits every resulting complex polygon sharing the same value into simple (or singlepart) polygons.
+ Variant 1: ST_DumpAsPolygons(raster) -> geomval set -- default to band # 1
+ This function should be used with precaution on raster with float pixel type as it could return one "geomval" (or polygon) per pixel. This kind of raster should be reclassified (using the planned ST_Reclassify(raster,...) function) before using ST_DumpAsPolygons().
  '''Implementation details'''
 …
  The "CONTIGUOUS" version could be implemented by "dumping" (see geometry_dump in PostGIS) the complex polygon into separate simple polygons.
  To avoid linking directly with PostGIS (see "Why avoid to link with PostGIS?" below) It should be implemented as a SQL wrapper around ST_AsWKTPolygon() looking something like this:
+ To avoid linking directly with PostGIS (see "Why avoid to link with PostGIS?" below) It should be implemented as a SQL wrapper around DumpAsWKTPolygons() looking something like this:
  CREATE TYPE geomval AS (geom geometry, val float8);[[BR]]
  CREATE TYPE wktgeomval AS (wktgeom text, val float8);
  CREATE OR REPLACE FUNCTION ST_AsPolygon(rast raster) RETURNS SETOF geomval AS $$[[BR]]
      SELECT ST_GeomFromText(wktgeomval.wktgeom), wktgeomval.val FROM ST_AsWKTPolygon(%1) AS wktgeomval;[[BR]]
+ CREATE OR REPLACE FUNCTION ST_DumpAsPolygons(rast raster) RETURNS SETOF geomval AS $$[[BR]]
+     SELECT ST_GeomFromText(wktgeomval.wktgeom), wktgeomval.val FROM DumpAsWKTPolygons(%1) AS wktgeomval;[[BR]]
  $$ LANGUAGE SQL;
  It should then be used like this:
  SELECT (gv).val, (gv).geom FROM (SELECT ST_AsPolygon(rast) gv FROM sometable) foo
+ SELECT (gv).val, (gv).geom FROM (SELECT ST_DumpAsPolygons(rast) gv FROM sometable) foo
 [[Image(WKTRasterAsPolygon.gif)]]
 '''ST_AsWKTPolygon(raster, integer) -> wktgeomval set''' - Returns a set of "geomval" value, one for each group of pixel sharing the same value for the provided band.
  Variant 1: ST_AsWKTPolygon(raster) -> wktgeomval set -- default to band # 1
+'''DumpAsWKTPolygons(raster, integer) -> wktgeomval set''' - Returns a set of "geomval" value, one for each group of pixel sharing the same value for the provided band.
+ Variant 1: DumpAsWKTPolygons(raster) -> wktgeomval set -- default to band # 1
  This is a set-returning function (SRF). A "wktgeomval " value is a complex type composed of a the wkt representation of a geometry (one for each group of pixel sharing the same value) and the value associated with this geometry. These values are always returned as a value of type double precision. The shape of each polygon follow pixels edges. Areas with NODATA values are not included in the resulting set.
  This function should be used with precaution on raster with float pixel type as it could return one "geomval" (or polygon) per pixel. This kind of raster should be reclassified (using the planned ST_Reclassify(raster,...) function) before using ST_AsWKTPolygon().
  ST_AsWKTPolygon() should not be used directly. Use ST_AsPolygon() instead.
+ This function should be used with precaution on raster with float pixel type as it could return one "geomval" (or polygon) per pixel. This kind of raster should be reclassified (using the planned ST_Reclassify(raster,...) function) before using DumpAsWKTPolygons().
+ DumpAsWKTPolygons() should not be used directly. Use ST_DumpAsPolygons() instead.
  '''Implementation details'''
 …
 ) If the first test returns TRUE, it checks if the geometry returned by ST_ConvexHull(raster) intersects with the geometry.
 ) If the second test returns TRUE, it checks if the geometry returned by ST_Shape(raster, integer) 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 test takes NODATA values into account. i.e. A geometry intersecting only with a NODATA value area of a raster is NOT actually not intersecting with this raster. This behavior may be controled by limiting the test to certain conditions as stated below.
+) If the second test returns TRUE, it checks if the geometry returned by ST_Polygon(raster, integer) 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 test takes NODATA values into account. i.e. A geometry intersecting only with a NODATA value area of a raster is NOT actually not intersecting with this raster. This behavior may be controled by limiting the test to certain conditions as stated below.
  Variant 4 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).
 …
   ST_Intersection(raster, raster, 'geometry') -> geometry -- default both raster to band # 1
  This is a set-returning function (SRF). It returns a set of "geomval" representing the point set intersection of the geometry and the areas of the raster sharing a common meaningfull value (NODATA values ARE taken into account). The raster is first polygonised using ST_AsPolygon(raster) and ST_Intersection(geometry, geometry) is then performed between the provided geometry and all the geometries resulting from the polygonisation of the raster.
+ This is a set-returning function (SRF). It returns a set of "geomval" representing the point set intersection of the geometry and the areas of the raster sharing a common meaningfull value (NODATA values ARE taken into account). The raster is first polygonised using ST_DumpAsPolygons(raster) and ST_Intersection(geometry, geometry) is then performed between the provided geometry and all the geometries resulting from the polygonisation of the raster.
  If the geometries do not share any space (are disjoint), then an empty geometry collection is returned.
 …
  If you only want to compute the intersection between the shape of the raster without polygonising it to group of pixels sharing a common value, do:
   ST_Intersection(ST_Shape(raster), geometry)
+  ST_Intersection(ST_Polygon(raster), geometry)
  '''Implementation details'''
  This function should be implemented as a pl/pgSQL function (possibly only a SQL function) performing the intersection between the provided geometry and the table generated by ST_AsPolygon(raster).
+ This function should be implemented as a pl/pgSQL function (possibly only a SQL function) performing the intersection between the provided geometry and the table generated by ST_DumpAsPolygons(raster).
  Priority 1 should be given to the raster/geometry variants (original and variant 1) returning a geometry.
 …
   a. ML: ST_AsTIFF - Do we aim to depend on libgeotiff?[[BR]][[BR]]
   a. ML: Is there any function that would require/fit GDAL dependency?[[BR]][[BR]]
   a. Pierre: We should maybe investigate the cost of using GDAL and have a general ST_AsImage(format, params) instead of using the individual tiff, jpeg and png libraries. Those will anyway also have a cost I guess... And we will probably have to link with GDAL for AsPolygon(rast) and AsRaster(geom) anyway.[[BR]][[BR]]
+  a. Pierre: We should maybe investigate the cost of using GDAL and have a general ST_AsImage(format, params) instead of using the individual tiff, jpeg and png libraries. Those will anyway also have a cost I guess... And we will probably have to link with GDAL for DumpAsPolygons(rast) and AsRaster(geom) anyway.[[BR]][[BR]]
 . '''Implementing raster -> vector conversion for intersections().''' How to do it? Possible using only plpgsql? So we don't have to link with liblwgeos and we can have our own release schedule.
    * polygonize with GDAL or GRASS, that generates some internal structure for those libraries, and you turn that into a WKT form of polygon. That can be passed to PostGIS, and you don't need to link to liblwgeom.[[BR]][[BR]]