wiki:WKTRaster/Documentation01

Version 36 (modified by pracine, 14 years ago) ( diff )

—

PostGIS WKT Raster Beta 0.1.6 Documentation


1 - Introduction

WKT Raster is an extension of PostGIS aiming at aiming at developing support for raster. It is a new project very different from the previous PGRaster project and also very different from Oracle GeoRaster…

WKT Raster's goal is to implement the RASTER type as much as possible like the GEOMETRY type is implemented in PostGIS and to offer a single set of overlay SQL functions (like ST_Intersects) operating seamlessly on vector and raster coverages.

WKT Raster…

…is as simple as PostGIS…

Load your raster data using gdal2wktraster.py and make your queries! In WKT Raster…

  • RASTER is a new column type (like the PostGIS GEOMETRY type)
  • one table with a column of type raster = one raster coverage (like a one table PostGIS vector coverage)
  • one table row with a column of type raster = one tile (like a one row PostGIS vector geometry feature)
  • each raster tile has: a pixel size, a width and a height, a georeference, a variable number of band, a pixeltype per band and a nodata value per band; everything essential to do basic GIS raster operations.

…is an extension of PostGIS to be installed separately…

  • installable over any version of PostGIS higher than 1.3.5.
  • merge with PostGIS might occur in the future…

…has a loader similar to shp2pgsql.exe (gdal2wktraster.py)…

…allows easy conversion from raster to geometry…

  • RT_AsPolygon(raster) → geometry

…introduces raster/geometry seamless geometry constructors…

  • so you don't have to bother whether the layers you are working with are in raster or vector form when using analysis functions.
  • RT_Intersection(raster|geometry, raster|geometry, "raster"|"geometry") → raster/geometry

…and seamless geometry operators…

  • raster|geometry && raster|geometry → boolean
  • RT_Intersects(raster|geometry, raster|geometry) → boolean

…allows raster storage INSIDE the database (as WKB)…

  • for efficient overlay analysis operations between vector and raster layers…

…or OUTSIDE the database (as JPEG or TIFF)…

  • so desktop and web applications can quickly access and load raster tiles and nevertheless benefits from the powerful PostGIS GiST spatial index. Every WKT Raster SQL functions working with in-the-db raster tiles work seamlessly with out-the-db raster tiles.

…introduces the concept of raster objects…

  • geographic features are stored as variable size raster tiles instead of polygons.
  • allows vector to raster conversion without lost of information.

…is much more simple than PGRaster and Oracle GeoRaster! WKT Raster supports…

  • only one type (instead of two in Oracle Spatial: SDO_GEORASTER & SDO_RASTER). In WKT Raster there are no differences between rasters and tiles: a tile is a raster and a raster is a tile. i.e. one row = one tile = one raster; one table = one raster coverage.
  • no metadata (like PostGIS)
  • no masks (you can create a mask as a band)
  • no multiple dimensions (only two: x, y). Not to be confused with bands; WKT Raster DO supports multiband raster…
  • no pyramids (reduced resolution coverages can be stored as a separate layer)

1.1 - Credits

Sponsoring

  • ​Steve Cumming, University Laval, sponsored project management kick-start and core implementation.
  • ​CadCorp sponsored WKB and datum format design and implementation.

Development

  • Pierre Racine designed the functionality.
  • Sandro Santilli wrote the in-memory api, build scripts and postgresql connectors.
  • Mateusz Loskot wrote the loader (gdal2wktraster.py) and most "getter" functions.

1.2 - More Information

2 - Installation

2.1 - Requirements

WKT Raster is dependent on:

2.2 - Installing Precompiled Binaries

Windows and Linux binaries should be available soon on the ​WKT Raster Home Page.

2.3 - Compiling and Installing from Sources

2.3.1 - Compiling on Linux

  1. Follow the ​instructions to compile PostGIS.
  2. Using a SVN client, retrieve the WKT Raster source from ​http://svn.osgeo.org/postgis/spike/wktraster
  3. From the wktraster directory, run: 
>./configure

  1. Run the compile and install commands: 
>make & make install

PostgreSQL provides a utility called pg_config to enable extensions like PostGIS to locate the PostgreSQL installation directory. If ./configure didn't find pg_config, try using the —with-pgconfig=/path/to/pg_config switch to specify a particular PostgreSQL installation.

All files are installed using information provided by pg_config:

  • Core functionality (rtpostgis shared library) is installed in [pkglibdir]/lib/
  • SQL function file (rtpostgis.sql) is installed in [prefix]/share/contrib
  • Loader (gdal2wktraster.py) is installed in [bindir]/

2.3.2 - Compiling on Windows using MSYS/MinGW

  1. Compile PostGIS using these instructions.
  1. From the wktraster folder, do: 
>./configure --with-postgis-sources=/usr/src/postgis-svn
>$ make

Note that the 'configure' script isn't there if you fetched the code from the SVN repository. In that case running ./autogen.sh should create it for you.

Under MinGW you might have to add "—with-pgconfig=/usr/local/pgsql/bin/pg_config" if configure can't find your pgsql path.

2.3.3 - Compiling on Windows using Visual Studio

2.3.4 - Final Installation

  1. Load the PostGIS WKT Raster object and function definitions into your database by loading the rtpostgis.sql definitions file. 
>psql -d [yourdatabase] -f rtpostgis.sql

The PostGIS WKT Raster extensions should now be loaded and ready to use.

3 - Using PostGIS WKT Raster

3.1 - The PostGIS WKT Raster Type

Like the PostGIS "geometry" type, the PostGIS WKT "raster" type is a new PostgreSQL type. This means each raster or raster tile is stored as a row of data in a PostgreSQL database table. It is a complex type, embedding information about the raster itself (width, height, number of bands, pixeltype for each band and nodata value for each band) along with its geolocalisation (pixelsize, upper left pixel center, rotation and SRID).

3.1.1 - PostGIS WKT Raster Rationale

WKT Raster was designed with many objectives, to accommodate a myriad of dataset structures and a diversity of applications:

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.

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:

  • 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 existing applications to work with new data loaded as rasters without (many) changes (to a certain conceptual limit).

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.

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.

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.

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:

  • 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.

This is "out-db" storage as opposed to the more natural "in-db" storage.

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.)

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.

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…

Hence, a single attribute of type raster can store:

  • a "complete image" (e.g. Landsat),
  • an image "tile",
  • a "raster object"; a new kind of raster object introduced by PostGIS WKT Raster resulting from the rasterization of a vector feature.

All these objects are different terminologies and concepts related to the general concept of "raster". We will use the latter term throughout the rest of this documentation.

Similarly, a table with a column of type raster may be seen, depending on the structure and the relationships between the raster objects it contains, as storing (Table 1 provides a summary of the characteristics inherent to each arrangement, and figure 1 provides a corresponding graphical representation of each one.):

a) an image warehouse of untiled and (possibly) unrelated images. These images may or may not overlap since every image has its own georeference. They may also have no georeference at all.

b) an irregularly tiled raster coverage. It might not necessarily be rectangular, there might be some missing tiles, and they might be different sizes. Tiles should not overlap.

c) a regularly tiled raster coverage. It might not necessarily be rectangular, there might be some missing tiles, and the tiles should be the same size. Tiles should not overlap.

d) a rectangular regularly tiled raster coverage. It is necessarily rectangular, there are no missing tiles, they are all the same size and they do not overlap.

e) a tiled image. It is necessarily rectangular, there are no missing tiles, they are all the same size, and they do not overlap. This type is different from type d) in that it does not represent a complete coverage; other images forming the rest of the coverage are stored as other tables of tiled images. This structure is not very practical from a GIS analytical point of view since any operations applied to the coverage must also be applied to every table.

f) a raster object coverage resulting from the rasterization of a vector coverage. Each vector feature becomes a small raster with the same extent as the original vector feature. This type of coverage is not necessarily complete, nor rectangular; tiles should be of different sizes and might overlap. It all depends on the characteristics of the vector layer being rasterized. An exhaustive (or continuous) layer of mutually exclusive geometries (without gaps or holes like a forest cover) would result in a raster object coverage in which significant pixels (withdata values) would not overlap, but non-significant pixels (nodata values) would. On the other end of the spectrum, a discontinuous layer of mutually exclusive geometries (like a lake or building layer) would result in a coverage of mostly disjoint raster objects.

Table 1 - Characteristics of possible different raster table arrangements in PostGIS WKT Raster

Arrangement Global shape of
composing raster 		Missing tiles
possible 		Same size
tiles 		Tile overlap
possible 		Form a
coverage?
a) image warehouse of untiled and unrelated images any no tiles no tile yes No
b) irregularly tiled raster coverage any yes no no yes
c) regularly tiled raster coverage any yes yes no yes
d) rectangular regularly tiled raster coverage strictly rectangular no yes no yes
e) tiled image strictly rectangular no yes no not as a single table
f) raster object coverage any no real tiles no real tiles yes yes

Figure 1 - Different possible raster table arrangements in PostGIS WKT Raster

3.2 - Integration with PostGIS

3.3 - Loader/Dumper

3.4 - Building Indexes

3.5 - Examples

4 - Uploading Strategy & Performance Tips


5 - PostGIS WKT Raster Reference

5.1 - Management Functions

5.2 - Raster Relationship Functions

5.3 - Raster Processing Functions

5.4 - Raster Accessors

5.5 - Raster Constructors

5.6 - Raster Operators

5.7 - Raster Outputs

5.8 - Raster Editors

6 - Reporting Problems


Appendix

Attachments (1)

Download all attachments as: .zip

Note: See TracWiki for help on using the wiki.