Changes between Version 182 and Version 183 of WKTRaster/SpecificationWorking03

Timestamp:

Nov 29, 2011, 2:43:34 PM (12 years ago)

Author:

pracine

Comment:

—

WKTRaster/SpecificationWorking03

@@ -529 +529 @@
 Following the conversion of geometry_columns to a view in PostGIS, it is planned to do the same with raster_column and raster_overview for the raster part. Converting to a view has a number of advantages:
 
- * The raster_column view rows will always be in synch with the existing list raster columns
+ * The raster_column view rows will always be in synch with the existing list raster columns.
+
  * All the information will be trustworthy because it will be enforced by constraints, so people can't change the band types etc... without changing the constraints. The raster_columns information will always be null (if the constraint does not apply) or correct.
 
+ * Idem for the raster_overview table.
+
 PostGIS is using the typmod feature of PostgreSQL to 'store' metadata about a table and then display them in the geometry_column view. Unfortunately the typmod is limited to XXX byte and there is too much information to 'store' about a raster table to use typmod. PostGIS raster will therefore use another approch consisting in 'store' metadata about a raster table as constraint on the table. A set of constraint will be applied to a raster table and those constraint will be read and displayed by the raster_column view.
 
 The major changes concerning the raster_column table are as follow:
 
- * There will be a flexible ApplyRasterConstraint() function trying to apply a set of constraint on a table. As for any constraint, the constraints will be successfully applied only when all the rows of the table fulfil the constraint.
-
- * This function will be called by the new C raster2pgsql C loader.
+ * There will be a flexible ApplyRasterConstraint() function trying to apply a set of constraint on a table. As for any constraint, the constraints will be successfully applied only when all the rows of the table fulfil the constraint. The list of potential constraint applied by the C loader (using the ApplyRasterConstraint function) and hence the list of column available in the raster_column view will be: srid int, scalex float8, scaley float8, width int, height int, alignment (align on a upperleft x and y), numberofband int, pixeltypes text[], nodatavalues float[] in addition to the 'r_table_catalog', 'r_table_schema', 'r_table_name' and 'r_column' columns.
+
+There is still discussion to know if extent as a geometry should be added to this list. Comments are welcomes.
 
  * The raster_column view rows will be determined by querying the PostgreSQL catalog. A typical query exist for this.
@@ -544 +547 @@
  * The raster_column will derive columns of metadata from the constraints applied to each table listed. When a constraint could not be applied successfully to the table, the column for this table will be null.
 
-The major changes concerning the raster_column table are as follow:
-
- * We will provide two functions to support the creation of the raster_overview view and application of two additional constraints specific to overviews (ApplyOverviewConstraints) and a function for creating overviews (ST_CreateOverview()).
-
- * The raster_overview table will NOT be created by default by the rtpostgis.sql script. It will be up to applications to use the ApplyOverviewConstraints and ST_CreateOverview() function to enable overviews support.
+The major changes concerning the raster_overview table are as follow:
+
+ * The raster_overview table will also be replaced with a raster_overview view.
+
+ * We will provide a new function to support the creation of the raster_overview view and application of three additional constraints specific to overviews (!ApplyOverviewConstraints) and a function for creating overviews (ST_CreateOverview()). Three additional constraints will be applied when using the !ApplyOverviewConstraints fucntion: 'reference raster table oid', 'overview factor' and 'global extent'. Those constraints will be displayed by the raster_overview view as 'r_table_catalog', 'r_table_schema', 'r_table_name', 'r_column', 'overview_factor' and 'global_extent' in addition to the 'o_table_catalog', 'o_table_schema', 'o_table_name' and 'o_column' columns.
+
+ * The raster_overview table will NOT be created by default by the rtpostgis.sql script. It will be the responsibility of applications to use the !ApplyOverviewConstraints and ST_CreateOverview() function to enable overviews support.
 
  The major changes concerning the raster2pgsql loader are as follow:
@@ -554 +559 @@
  * We are working on a new C importer to get rid of any Python, Numpy and Python GDAL binding dependency.
 
+ * This new loader will attempt to apply the constraint on the loaded table using the ApplyRasterConstraint()function. There will be an option to NOT trying to apply the constraint for applications not wishing to use the raster_column table. 
+
  * This new importer will NOT have any option to create the raster_overview view, nor to create overview tables. We think that it is more important to be able to create overview in SQL as a post process query so overviews can be updated/recreated when rasters tiles are edited, added or deleted.
 
@@ -559 +566 @@
 
 
-'''More Details'''
+
+
+
 
 ----