| 527 | | == '''Objective FV.22 - Making raster_columns and raster_overview as views''' == |
| 528 | | |
| 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: |
| 530 | | |
| 531 | | * The raster_column view rows will always be in synch with the existing list raster columns. |
| 532 | | |
| 533 | | * 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). |
| 534 | | |
| 535 | | * Idem for the raster_overview table. |
| 536 | | |
| 537 | | 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. |
| 538 | | |
| 539 | | The '''major changes concerning the raster_column table''' are as follow: |
| 540 | | |
| 541 | | * There will be a flexible !AddRasterConstraint() function trying to add 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 !AddRasterConstraint 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. |
| 542 | | |
| 543 | | * The raster_column view rows will be determined by querying the PostgreSQL catalog. A typical query exists for this. |
| 544 | | |
| 545 | | * 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 !AddRasterconstraint()), the column corresponding to this constraint for this table will be null. |
| 546 | | |
| 547 | | The '''major changes concerning the raster_overview table''' are as follow: |
| 548 | | |
| 549 | | * The raster_overview table will also be replaced by a raster_overview view. |
| 550 | | |
| 551 | | * We will provide a new function to support the creation of the raster_overview view and application of three additional constraints specific to overviews (!AddOverviewConstraints). These three additional constraints are: '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. |
| 552 | | |
| 553 | | * We will also provide a SQL function for creating overviews (ST_CreateOverview(schemaname text, tablename teat, columnname, factor int)). |
| 554 | | |
| 555 | | * 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 !AddOverviewConstraints and ST_CreateOverview() function to create the raster_overviews view and create overviews. |
| 556 | | |
| 557 | | The '''major changes concerning the raster2pgsql loader''' are as follow: |
| 558 | | |
| 559 | | * We are working on a new C importer to get rid of any Python, Numpy and Python GDAL Binding dependency which is a major obstacle to successful installation of PostGIS 2.0. |
| 560 | | |
| 561 | | * This new loader will attempt to add the constraints on the loaded table using the !AddRasterConstraint() function. There will be an option to NOT try to add the constraint for applications preferring to have no constraint applied to the tables over having a raster_column view filled with the proper information. |
| 562 | | |
| 563 | | * This new importer will NOT have any option to create the raster_overview view, nor to create overview tables as we leave this to the application. We also think that it is more important to be able to create overviews in SQL as a post loading process query so overviews can be updated/recreated when rasters tiles are edited, added or deleted. Application wishing to create overview can implement their own overview creation code or just use the future ST_CreateOverview() SQL function. |
| 564 | | |
| 565 | | * 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 addaptation (to the new !AddRasterConstraints() and !AddOverviewConstraints() functions). |
| 566 | | |
| 567 | | |
| 568 | | ---- |
| | 3764 | ---- |
| | 3765 | == '''Objective FV.22 - Making raster_columns and raster_overview as views''' == |
| | 3766 | |
| | 3767 | raster_columns and raster_overviews are now constraint-based views. The structure of the raster_columns views is below. |
| | 3768 | |
| | 3769 | {{{ |
| | 3770 | #!html |
| | 3771 | <TABLE BORDER=1> |
| | 3772 | <THEAD> |
| | 3773 | <TR> |
| | 3774 | <TH ALIGN=LEFT>Column</TH> |
| | 3775 | <TH ALIGN=LEFT>PostgreSQL Type</TH> |
| | 3776 | <TH ALIGN=LEFT>Description</TH> |
| | 3777 | </TR> |
| | 3778 | </THEAD> |
| | 3779 | <TBODY> |
| | 3780 | <TR> |
| | 3781 | <TD ALIGN=LEFT>r_table_catalog</TD> |
| | 3782 | <TD ALIGN=LEFT>name</TD> |
| | 3783 | <TD ALIGN=LEFT>Name of the database containing the table with the raster column.</TD> |
| | 3784 | </TR> |
| | 3785 | <TR> |
| | 3786 | <TD ALIGN=LEFT>r_table_schema</TD> |
| | 3787 | <TD ALIGN=LEFT>name</TD> |
| | 3788 | <TD ALIGN=LEFT>Name of the schema containing the table with the raster column.</TD> |
| | 3789 | </TR> |
| | 3790 | <TR> |
| | 3791 | <TD ALIGN=LEFT>r_table_name</TD> |
| | 3792 | <TD ALIGN=LEFT>name</TD> |
| | 3793 | <TD ALIGN=LEFT>Name of the table containing a column of type raster.</TD> |
| | 3794 | </TR> |
| | 3795 | <TR> |
| | 3796 | <TD ALIGN=LEFT>r_raster_column</TD> |
| | 3797 | <TD ALIGN=LEFT>name</TD> |
| | 3798 | <TD ALIGN=LEFT>Name of the raster column in the table. All attribute columns following this column apply to the rasters in this column. <span style="font-size: italic; font-weight: bold;">This column was previously known as r_column.</span></TD> |
| | 3799 | </TR> |
| | 3800 | <TR> |
| | 3801 | <TD ALIGN=LEFT>srid</TD> |
| | 3802 | <TD ALIGN=LEFT>integer</TD> |
| | 3803 | <TD ALIGN=LEFT>ID of the spatial reference system of the rasters in this column. Value is extracted from the ST_SRID constraint on this raster column. The constraint is typically named enforce_srid_<r_raster_column>.</TD> |
| | 3804 | </TR> |
| | 3805 | <TR> |
| | 3806 | <TD ALIGN=LEFT>scale_x</TD> |
| | 3807 | <TD ALIGN=LEFT>double precision</TD> |
| | 3808 | <TD ALIGN=LEFT>The scale on the X-axis of the rasters in this column. Value is extracted from the ST_ScaleX constraint on this raster column. The constraint is typically named enforce_scalex_<r_raster_column>.</TD> |
| | 3809 | </TR> |
| | 3810 | <TR> |
| | 3811 | <TD ALIGN=LEFT>scale_y</TD> |
| | 3812 | <TD ALIGN=LEFT>double precision</TD> |
| | 3813 | <TD ALIGN=LEFT>The scale on the Y-axis of the rasters in this column. Value is extracted from the ST_ScaleY constraint on this raster column. The constraint is typically named enforce_scaley_<r_raster_column>.</TD> |
| | 3814 | </TR> |
| | 3815 | <TR> |
| | 3816 | <TD ALIGN=LEFT>blocksize_x</TD> |
| | 3817 | <TD ALIGN=LEFT>integer</TD> |
| | 3818 | <TD ALIGN=LEFT>The width of the rasters in this column. Value is extracted from the ST_Width constraint on this raster column. The constraint is typically named enforce_width_<r_raster_column>.</TD> |
| | 3819 | </TR> |
| | 3820 | <TR> |
| | 3821 | <TD ALIGN=LEFT>blocksize_y</TD> |
| | 3822 | <TD ALIGN=LEFT>integer</TD> |
| | 3823 | <TD ALIGN=LEFT>The height of the rasters in this column. Value is extracted from the ST_Height constraint on this raster column. The constraint is typically named enforce_height_<r_raster_column>.</TD> |
| | 3824 | </TR> |
| | 3825 | <TR> |
| | 3826 | <TD ALIGN=LEFT>same_alignment</TD> |
| | 3827 | <TD ALIGN=LEFT>boolean</TD> |
| | 3828 | <TD ALIGN=LEFT>If TRUE, all rasters in this column are aligned. State is extracted from the ST_SameAlignment constraint comparing the rasters in this column against coordinates known to be on the grid. The constraint is typically named enforce_same_alignment_<r_raster_column>.</TD> |
| | 3829 | </TR> |
| | 3830 | <TR> |
| | 3831 | <TD ALIGN=LEFT>regular_blocking</TD> |
| | 3832 | <TD ALIGN=LEFT>boolean</TD> |
| | 3833 | <TD ALIGN=LEFT>If TRUE, all rasters in this column are regularly blocked. <span style="color: red; font-weight: bold;">Though this column is technically based upon a constraint, the constraint is purely information and does NO actual constraining. Therefore if this column is TRUE, a user explicitly specified that the rasters in this column are regularly blocked.</span> The constraint is typically named enforce_regular_blocking_<r_raster_column>.</TD> |
| | 3834 | </TR> |
| | 3835 | <TR> |
| | 3836 | <TD ALIGN=LEFT>num_bands</TD> |
| | 3837 | <TD ALIGN=LEFT>integer</TD> |
| | 3838 | <TD ALIGN=LEFT>The number bands within each raster of this column. Value is extracted from the ST_NumBands constraint on this raster column. The constraint is typically named enforce_num_bands_< r_raster_column>.</TD> |
| | 3839 | </TR> |
| | 3840 | <TR> |
| | 3841 | <TD ALIGN=LEFT>pixel_types</TD> |
| | 3842 | <TD ALIGN=LEFT>text[]</TD> |
| | 3843 | <TD ALIGN=LEFT>Text array of the pixel types of the bands within each raster of this column. Value is extracted from a special function that creates an array of the band pixel types of the rasters in this column. The constraint is typically named enforce_pixel_types_<r_raster_column>.</TD> |
| | 3844 | </TR> |
| | 3845 | <TR> |
| | 3846 | <TD ALIGN=LEFT>nodata_values</TD> |
| | 3847 | <TD ALIGN=LEFT>double precision[]</TD> |
| | 3848 | <TD ALIGN=LEFT>Double precision array of the NODATA values of the bands within each raster of this column. Value is extracted from a special function that creates an array of the band NODATA values of the rasters in this column. The constraint is typically named enforce_nodata_values_<r_raster_column>.</TD> |
| | 3849 | </TR> |
| | 3850 | <TR> |
| | 3851 | <TD ALIGN=LEFT>extent</TD> |
| | 3852 | <TD ALIGN=LEFT>geometry</TD> |
| | 3853 | <TD ALIGN=LEFT>The maximum extent within which all rasters of this column must be covered by. The maximum extent is computed by ST_ConvexHull(ST_Collect(ST_ConvexHull(raster))) of all rasters in this column at the time that the extent constraint was added.. Value is extracted from the ST_CoveredBy(ST_ConvexHull(raster)) constraint on this raster column. The constraint is typically named enforce_max_extent_<r_raster_column>.</TD> |
| | 3854 | </TR> |
| | 3855 | </TBODY> |
| | 3856 | </TABLE> |
| | 3857 | |
| | 3858 | }}} |
| | 3859 | |
| | 3860 | ~~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: |
| | 3861 | |
| | 3862 | ~~ * The raster_column view rows will always be in synch with the existing list raster columns. |
| | 3863 | |
| | 3864 | ~~ * 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). |
| | 3865 | |
| | 3866 | ~~ * Idem for the raster_overview table. |
| | 3867 | |
| | 3868 | ~~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. |
| | 3869 | |
| | 3870 | ~~The '''major changes concerning the raster_column table''' are as follow: |
| | 3871 | |
| | 3872 | ~~ * There will be a flexible !AddRasterConstraint() function trying to add 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 !AddRasterConstraint 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. |
| | 3873 | |
| | 3874 | ~~ * The raster_column view rows will be determined by querying the PostgreSQL catalog. A typical query exists for this. |
| | 3875 | |
| | 3876 | ~~ * 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 !AddRasterconstraint()), the column corresponding to this constraint for this table will be null. |
| | 3877 | |
| | 3878 | ~~The '''major changes concerning the raster_overview table''' are as follow: |
| | 3879 | |
| | 3880 | ~~ * The raster_overview table will also be replaced by a raster_overview view. |
| | 3881 | |
| | 3882 | ~~ * We will provide a new function to support the creation of the raster_overview view and application of three additional constraints specific to overviews (!AddOverviewConstraints). These three additional constraints are: '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. |
| | 3883 | |
| | 3884 | ~~ * We will also provide a SQL function for creating overviews (ST_CreateOverview(schemaname text, tablename teat, columnname, factor int)). |
| | 3885 | |
| | 3886 | ~~ * 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 !AddOverviewConstraints and ST_CreateOverview() function to create the raster_overviews view and create overviews. |
| | 3887 | |
| | 3888 | ~~The '''major changes concerning the raster2pgsql loader''' are as follow: |
| | 3889 | |
| | 3890 | ~~ * We are working on a new C importer to get rid of any Python, Numpy and Python GDAL Binding dependency which is a major obstacle to successful installation of PostGIS 2.0. |
| | 3891 | |
| | 3892 | ~~ * This new loader will attempt to add the constraints on the loaded table using the !AddRasterConstraint() function. There will be an option to NOT try to add the constraint for applications preferring to have no constraint applied to the tables over having a raster_column view filled with the proper information. |
| | 3893 | |
| | 3894 | ~~ * This new importer will NOT have any option to create the raster_overview view, nor to create overview tables as we leave this to the application. We also think that it is more important to be able to create overviews in SQL as a post loading process query so overviews can be updated/recreated when rasters tiles are edited, added or deleted. Application wishing to create overview can implement their own overview creation code or just use the future ST_CreateOverview() SQL function. |
| | 3895 | |
| | 3896 | ~~ * 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 addaptation (to the new !AddRasterConstraints() and !AddOverviewConstraints() functions). |
