Changes between Version 191 and Version 192 of WKTRaster/SpecificationWorking03

Timestamp:

Nov 30, 2011, 12:37:56 AM (12 years ago)

Author:

robe

Comment:

—

WKTRaster/SpecificationWorking03

@@ -531 +531 @@
  * 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 correct or null (if the constraint can not be not applied).
+ * 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 correct or null (if the constraint can not be applied).
 
  * 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 bytes and there is too much information to 'store' about a raster table to use typmod. PostGIS raster will therefore use another approach consisting in 'storing' 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.
+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 bytes and there is too much information to 'store' about a raster table to use typmod. PostGIS raster will therefore use another approach consisting of 'storing' metadata about a raster table as constraints on the table. A set of constraints will be applied to a raster table and those constraints 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, each constraint will be successfully applied only when all the rows of the table fulfil this 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, samealignment boolean, scalex float8, scaley float8, width int, height int, 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 about if global 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.
+ * There will be a flexible !ApplyRasterConstraint() function trying to apply a set of constraint on a table. As for any constraint, each constraint will be successfully applied only when all the rows of the table fulfill this 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, samealignment boolean, scalex float8, scaley float8, width int, height int, numberofbands 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 about if global extent as a geometry should be added to this list. Comments are welcome.
+
+ * The raster_column view rows will be determined by querying the PostgreSQL catalog. A typical query exists for this.
 
  * The raster_column view will derive columns of metadata from the constraints applied to each table listed. When a constraint does not exist (because it could not be applied successfully to the table by !ApplyRasterconstraint()), the column corresponding to this constraint for this table will be null.
@@ -553 +553 @@
  * We will also provide a SQL function for creating overviews (ST_CreateOverview(schemaname text, tablename teat, columnname, factor int)).
 
- * 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 create the raster_overviews view and create overviews.
+ * The raster_overview view 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 create the raster_overviews view and create overviews.
 
 The '''major changes concerning the raster2pgsql loader''' are as follow: