Changes between Version 29 and Version 30 of WKTRaster/Documentation01

Timestamp:

Dec 9, 2009, 12:18:30 PM (14 years ago)

Author:

pracine

Comment:

—

WKTRaster/Documentation01

@@ -204 +204 @@
 
  * may use their prior knowledge of PostGIS in general, and of its geometry type operators and functions, when building SQL queries;
- * expect similar behaviors when using these operators and functions with the raster type without having to consider whether their data are in vectorial or matricial form; 
+
+ * expect similar behaviors when using these operators and functions with the raster type without having to consider whether their data are in vectorial or matricial form;
+
  * expect existing applications to work with new data loaded as rasters without (many) changes (to a certain conceptual limit).
 
@@ -216 +218 @@
 
  * do not have to retrieve images from the database but might instead access them directly from the filesystem (e.g. as JPEG files);
+
  * can nevertheless use most PostGIS WKT Raster operators and functions on those rasters, transparently.
 
@@ -226 +229 @@
 We believe that these additional functionalities (over other raster-in-the-database implementations) make WKT Raster much more than just a new raster format, but also a necessary complement to PostGIS. 
 
+'''3.1.2 - PostGIS WKT Raster Implementation'''
+
+To fulfill these objectives, PostGIS WKT Raster implements a minimalistic yet complete raster data structure, and adopts a simple single-type and single-table relational schema. This data structure is very similar to the PostGIS geometry vector type structure, and very different, for example, from the Oracle Spatial SDO_GEORASTER and SDO_RASTER raster types.
+
+ * A single raster type - In PostGIS WKT Raster there is no such thing as a raster and its raster tiles or an image and its image tiles. Even though single raster attributes may be considered tiles of a coverage or tiles of an image, any attribute of type raster is a complete and self sufficient georeferenced raster. It is not necessarily related to other rasters in the same table, and not necessarily located in a specific grid. This choice makes everything very simple and flexible, letting users and applications decide how they structure their data and how they name their raster elements (rasters, images, bitmap, blocks, tiles, etc…).
+
+ * A single table relational schema – Similarly, in PostGIS WKT Raster there is not one table for storing the raster data (like Oracle Spatial SDO_RASTER) and another table for storing the georeference and the metadata (like Oracle Spatial SDO_GEORASTER). Everything is stored in a single raster attribute, and raster attributes composing a table are not necessarily related to each other to form a significant coverage.
+
+These choices make the PostGIS raster structure very similar to the existing PostGIS vector structure in which a layer can be geometrically topological or not, depending on the user data and their choice of application.
+
+This also means, contrary to most raster formats, that raster attributes from the same table:
+
+ * may be of different size. E.g. one raster can be 256 pixels wide and 256 pixels high while another can be 64 pixels wide and 64 pixels high.
+
+ * may "snap" to different grid. E.g. the upper left corner of a raster with a pixel size of 10m can be at 0,0 in a coordinate system with a map unit in meters, and the upper left corner of another raster with the same pixel size in the same coordinate system can be at 0,1.25. This means that pixels of different raster attributes are not necessarily grid aligned.
+
+ * may overlap, like polygons in a vector layer may overlap. This is fundamental to implementing meaningful vector to raster conversions in which all attributes accompanying a vector feature are conserved in the resulting raster table. E.g. 10 lake vector features with attributes like "name, type, area, perimeter, etc…" are converted to 10 lake raster features with the same attributes. In this case, even if the vector features and the “withdata values” part of the resulting raster features do not necessarily overlap, the "nodata values" of the raster features will overlap.
+
+These characteristics enable easy integration with vectors, but the flexibility also allows the loading of raster assemblages that are not necessarily suitable for geoanalysis. As with vector layers, you are responsible to ensure that your layer meets the minimum topological requirements for analysis. The ideal case is when all the raster tiles of a continuous layer are the same size, snap to the same grid and do not overlap…
+
 
 == '''3.2 - Integration with PostGIS''' ==