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

• allowing loading of a single raster or a set of rasters (using wildcard) into a tiled coverage.
• supporting ​as many file format as GDAL does.

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

• ​The Michigan Tech Research Institute sponsored spatial operators implementation.

• ​OSGeo provides svn repository.

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

• For more information see ​WKT Raster Home Page.

• Search for "WKT Raster" in the ​PostGIS-users and ​PostGIS-devel forums archives or in ​Nabble or write to these forums.

2 - Installation

2.1 - Requirements

WKT Raster is dependent on:

• ​PostgreSQL version 7.2 or higher.

• ​PostGIS version 1.3.5 or higher.

• ​Python version 2.5 or higher and ​GDAL for Python version 1.6.0 or higher for the loader (gdal2wktraster.py).

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

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

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

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