Changes between Version 181 and Version 182 of WKTRaster/SpecificationWorking03

Timestamp:

Nov 29, 2011, 2:19:10 PM (12 years ago)

Author:

pracine

Comment:

—

WKTRaster/SpecificationWorking03

@@ -527 +527 @@
 == '''Objective FV.22 - Making raster_columns and raster_overview as views''' ==
 
- 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:
+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
  * 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.
 
- 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:
+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.
@@ -544 +544 @@
  * 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:
+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()).
@@ -553 +553 @@
 
  * We are working on a new C importer to get rid of any Python, Numpy and Python GDAL binding dependency.
+
  * 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.
+
  * We will stop supporting the old raster2pgsql.py which was creating overview tables and filling the raster_overview table. It will be available in the script/python folder for people wishing to create overviews after a slight modification.
 
 
- '''More Details'''
+'''More Details'''
 
 ----