| 199 | | |
| 200 | | |
| 201 | | |
| 202 | | |
| 203 | | |
| 204 | | |
| 205 | | |
| 206 | | |
| 207 | | |
| 208 | | |
| 209 | | |
| 210 | | |
| 211 | | |
| 212 | | |
| 213 | | |
| 214 | | |
| 215 | | |
| 216 | | |
| 217 | | |
| 218 | | |
| 219 | | |
| 220 | | |
| 221 | | |
| 222 | | |
| 223 | | |
| 224 | | |
| 225 | | |
| 226 | | |
| 227 | | |
| 228 | | |
| 229 | | |
| | 199 | WKT Raster was designed with many objectives, to accommodate a myriad of dataset structures and a diversity of applications: |
| | 200 | |
| | 201 | '''Objective 1: Simplicity, Complementarity and Functionality -''' PostGIS WKT Raster provides a "raster" type that complements the existing PostGIS vectorial "geometry" type. This new extension offers operators and functions that are similar to those available with the existing geometry type. They work in the same user-friendly manner, but are associated with a matricial geospatial data structure to support the use of rasters. PostGIS WKT Raster also includes a simple loader to import many raster formats into the database. |
| | 202 | |
| | 203 | '''Objective 2: Seamless Integration with the PostGIS geometry type -''' PostGIS WKT Raster enables PostGIS operators and functions to work seamlessly on both raster and geometry types, so that users: |
| | 204 | |
| | 205 | * may use their prior knowledge of PostGIS in general, and of its geometry type operators and functions, when building SQL queries; |
| | 206 | |
| | 207 | * 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; |
| | 208 | |
| | 209 | * expect existing applications to work with new data loaded as rasters without (many) changes (to a certain conceptual limit). |
| | 210 | |
| | 211 | This makes PostGIS WKT Raster an abstraction level, not only over the raster format (like GDAL) or over the vector format (like OGR), but more generally over the two most used data structures in the geospatial industry (raster AND vector). Even if many operations performed on a vector object (e.g. all the functions working only on LINESTRING geometries) are not really possible to apply to raster objects, and if there are also some raster specific functions (e.g. ST_Resample() or ST_SetNoDataValue()) not working on vector objects, we think, and we will demonstrate as we extend PostGIS WKT Raster in the future, that most operations have their equivalent in both raster and vector worlds (e.g. ST_Intersections(), ST_Accum(), ST_Area(), ST_MapAlgebra()), even if this does not appear obvious at first sight. |
| | 212 | |
| | 213 | We think that providing a single paradigm (SQL) for dealing with both rasters and vectors should allow developers to write better GIS applications, by simplifying graphical user interfaces and softening the learning curves. Developers should be able to build a unique graphical user interface to deal with raster and vector data, making users having to learn only one set of operators to work with vector data and raster data, instead of two. We think this should generally enhance users’ experiences with geospatial applications and allow them to focus on real geographic problems rather than struggling with data formats and structures. |
| | 214 | |
| | 215 | We also think that this approach is compliant (at least in philosophy) with the ISO 19123 "Abstract Specification Schema for Coverage Geometry and Functions" specification (not to be confused with the OCG Web Coverage Service) in which a coverage can be represented as a point layer, a polygon layer, a TIN layer or a raster layer, and in which any positional value of the coverage is accessible without having to know the data structure upon which the coverage is based. |
| | 216 | |
| | 217 | '''Objective 3: Storage Flexibility (in-db & out-db storage) -''' PostGIS WKT Raster enables the user to simply "register" basic metadata (pixeltype, with, height, georeference, etc…) of images stored in the filesystem, without having to actually load their data values into the database. This way, web or desktop applications: |
| | 218 | |
| | 219 | * do not have to retrieve images from the database but might instead access them directly from the filesystem (e.g. as JPEG files); |
| | 220 | |
| | 221 | * can nevertheless use most PostGIS WKT Raster operators and functions on those rasters, transparently. |
| | 222 | |
| | 223 | This is "out-db" storage as opposed to the more natural "in-db" storage. |
| | 224 | |
| | 225 | '''Objective 4: Interoperability –''' WKT Raster uses GDAL (http://www.gdal.org/) as its main connector to filesystem raster files. GDAL is involved when loading rasters into the database (using the loader) and when working with out-db rasters. It enables WKT Raster to work with nearly a hundred different file formats. (For a complete list of supported file formats see http://www.gdal.org/formats_list.html). (GDAL is also used to implement some raster processing functions, but this is another matter.) |
| | 226 | |
| | 227 | Objectives 2 and 3 respond to the most discussed idea that "storing rasters in the database is slower and useless if it does not benefit from specific databases’ features". Objective 2 makes WKT Raster an analytical toolkit, going beyond the simple data format. Objective 3 ensures storage flexibility, retrieval efficiency and transparency to users. Both objectives benefit greatly from the indexing of raster data in the database. |
| | 228 | |
| | 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. |
| 233 | | |
| 234 | | |
| 235 | | |
| 236 | | |
| 237 | | |
| 238 | | |
| 239 | | |
| 240 | | |
| 241 | | |
| 242 | | |
| 243 | | |
| 244 | | |
| 245 | | |
| 246 | | |
| 247 | | |
| 248 | | |
| 249 | | |
| | 233 | 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. |
| | 234 | |
| | 235 | * 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…). |
| | 236 | |
| | 237 | * 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. |
| | 238 | |
| | 239 | 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. |
| | 240 | |
| | 241 | This also means, contrary to most raster formats, that raster attributes from the same table: |
| | 242 | |
| | 243 | * 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. |
| | 244 | |
| | 245 | * 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. |
| | 246 | |
| | 247 | * 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. |
| | 248 | |
| | 249 | 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… |
