General concepts - Useful 3rd party tools

Introduction: input formats directly supported by RasterLite2

You can directly create and populate a RasterLite2 Coverage by importing raw raster data from some external datasource; currently supported formats are:

TIFF raster files; a very flexible format supporting any possible kind of raster data, this including the most exotic SampleTypes and MultiBand. TIFF isn't a simple format; many different options and several alternative layouts are actually supported.
Thinking of TIFF as it was more a whole family than a single format will usually help to understand better all the complexity hidden under the generic TIFF name.
JPEG images; a very popular photographic format, supporting both Grayscale (Black & White) and TrueColor images.
JPEG support a very limited selection of raster data (just UINT8 GRAYSCALE and UINT8 RGB) but is often attractive because it supports strong compression ratios thus widely reducing storage sizes.
Anyway JPEG adopts a lossy compression, and consequently using JPEG images as an input datasource always implies a more or less severe quality degradation; under this aspect TIFF usually is a widely superior format, although it would often require bigger sizes.
ASCII Grid files; this simply is a format based on structured plain text.
It usually requires huge storage amounts, but it's easily supported by many different tools; and you can simply edit an ASCII Grid using any powerful text editor.
The ASCII Grid format simply support single-band rasters, but can flexibly support any possible SampleType.

Any raster datasource usually requires some kind of appropriate georeferencing in order to be used for geographic purposes:

TIFF images can be eventually georeferenced by an accompanying external WorldFile (we'll see below in more detail how WoldFiles work).
But an alternative strictly related format exists, i.e. GeoTIFF. Any GeoTIFF file still continues to be a standard and full-conformant TIFF file, but will internally include any related georeferencing information without requiring any further external file.
Anyway it's a common practice to release and distribute fully qualified GeoTIFFs actually accompanied by their corresponding WorldFiles; in this case there is some obvious information redundancy, but you can indifferently use the one or the other georeferencing method with identical results.
JPEG images as well could by supported by some accompanying external WorldFile.
The ASCII Grid format always supports explicit georeferencing declarations (we'll see below this facet in more depth).

Exploring TIFF internal details

A nice and useful tiffinfo tool is directly supported by libtiff. You'll usually find this tool directly supported on any Linux system (may be that installing the optional tiff-tools package could be required); but it's not at all difficult to install this tool even on Windows or MacOsX systems.
A closely related and very similar tool is listgeo, which is directly supported by libgeotiff
Both them are CLI tools, so you simply have to invoke the tool from a command shell by specifying the pathname of the TIFF file you intend to examine.

$ tiffinfo TrueMarble.2km.21600x10800.tif
TIFF Directory at offset 0x2fa01eea (799022826)
  Image Width: 21600 Image Length: 10800
  Tile Width: 512 Tile Length: 512
  Bits/Sample: 8
  Sample Format: unsigned integer
  Compression Scheme: None
  Photometric Interpretation: RGB color
  Samples/Pixel: 3
  Planar Configuration: single image plane
  Tag 33550: 0.016667,0.016667,0.000000
  Tag 33922: 0.000000,0.000000,0.000000,-180.000000,90.000000,0.000000
  Tag 34735: 1,1,0,5,1024,0,1,2,1025,0,1,1,2048,0,1,4326,2049,34737,7,0,2054,0,1
,9102
  Tag 34737: WGS 84|
$

In this first example tiffinfo is reporting that:

this raster does contain 21,600 x 10,800 pixels (Image Width and Image Length).
each pixel has 3 bands (Samples/Pixel) of the UINT8 type (Sample Format: unsigned integer and Bits/sample: 8).
a Photometric Interpretation of the RGB type is explicitly required.
the image has full uncompromised quality and isn't compressed (Compression Scheme: None).
the internal layout of this TIFF is of the tiled type (Tile Width and Tile Length), and each tile contains 512 x 512 pixels.
all band values are contiguously stored one after the other (Planar Configuration: single image plane).

$ listgeo TrueMarble.2km.21600x10800.tif
Geotiff_Information:
   Version: 1
   Key_Revision: 1.0
   Tagged_Information:
      ModelTiepointTag (2,3):
         0                 0                 0
         -180              90                0
      ModelPixelScaleTag (1,3):
         0.0166666666666667 0.0166666666666667 0
      End_Of_Tags.
   Keyed_Information:
      GTModelTypeGeoKey (Short,1): ModelTypeGeographic
      GTRasterTypeGeoKey (Short,1): RasterPixelIsArea
      GeographicTypeGeoKey (Short,1): GCS_WGS_84
      GeogCitationGeoKey (Ascii,7): "WGS 84"
      GeogAngularUnitsGeoKey (Short,1): Angular_Degree
      End_Of_Keys.
   End_Of_Geotiff.

GCS: 4326/WGS 84
Datum: 6326/World Geodetic System 1984
Ellipsoid: 7030/WGS 84 (6378137.00,6356752.31)
Prime Meridian: 8901/Greenwich (0.000000/  0d 0' 0.00"E)

Corner Coordinates:
Upper Left    (180d 0' 0.00"W, 90d 0' 0.00"N)
Lower Left    (180d 0' 0.00"W, 90d 0' 0.00"S)
Upper Right   (180d 0' 0.00"E, 90d 0' 0.00"N)
Lower Right   (180d 0' 0.00"E, 90d 0' 0.00"S)
Center        (  0d 0' 0.00"W,  0d 0' 0.00"N)
$

And for the same image (actually: a GeoTIFF image) listgeo is reporting that:

this raster adopts the WGS 84 Reference System (aka SRID 4326).
the overall extension spans between longitudes -180 and +180; and between latitudes -90 and +90.
each pixel covers 0.0166666666666667 decimal degrees, and all pixels have an exactly square shape (because scale factors are the same on both axes).

yet another example

$ tiffinfo 3v050307m0000654221a520004300502m_001665044_1GST.TIF
TIFF Directory at offset 0x8c483f7 (147096567)
  Subfile Type: (0 = 0x0)
  Image Width: 2218 Image Length: 8275
  Resolution: 1, 1
  Bits/Sample: 16
  Sample Format: unsigned integer
  Compression Scheme: None
  Photometric Interpretation: RGB color
  Orientation: row 0 top, col 0 lhs
  Samples/Pixel: 4
  Rows/Strip: 1
  Planar Configuration: separate image planes
  Tag 33550: 4.060000,4.060000,0.000000
  Tag 33922: 0.000000,0.000000,0.000000,676660.573232,4730184.769926,0.000000
  Tag 34735: 1,1,0,5,1024,0,1,1,1025,0,1,1,2052,0,1,9001,2054,0,1,9102,3072,0,1,
32632
  Tag 34737: WGS-84
$

In this second example tiffinfo is reporting that:

this raster does contain 2,218 x 8,275 pixels.
each pixel has 4 bands (Samples/Pixel) of the UINT16 type (Sample Format: unsigned integer and Bits/sample: 16).
a Photometric Interpretation of the RGB type is explicitly required; so the first three bands surely corresponds to Red, Green and Blue components.
Anyway there is an extra fourth band; in this case actually corresponding to InfraRed, but this further information isn't directly supported by the TIFF itself. Consulting the accompanying metadata is absolutely required in this case.
the image is not compressed.
the internal layout of this TIFF is of the striped type (Rows/Strip), and each strip contains just 1 scanline.
all band values are separately stored on their own (Planar Configuration: separate image planes).

$ listgeo 3v050307m0000654221a520004300502m_001665044_1GST.TIF
Geotiff_Information:
   Version: 1
   Key_Revision: 1.0
   Tagged_Information:
      ModelTiepointTag (2,3):
         0                 0                 0
         676660.573231925  4730184.7699264   0
      ModelPixelScaleTag (1,3):
         4.06              4.06              0
      End_Of_Tags.
   Keyed_Information:
      GTModelTypeGeoKey (Short,1): ModelTypeProjected
      GTRasterTypeGeoKey (Short,1): RasterPixelIsArea
      GeogLinearUnitsGeoKey (Short,1): Linear_Meter
      GeogAngularUnitsGeoKey (Short,1): Angular_Degree
      ProjectedCSTypeGeoKey (Short,1): PCS_WGS84_UTM_zone_32N
      End_Of_Keys.
   End_Of_Geotiff.

PCS = 32632 (WGS 84 / UTM zone 32N)
Projection = 16032 (UTM zone 32N)
Projection Method: CT_TransverseMercator
   ProjNatOriginLatGeoKey: 0.000000 (  0d 0' 0.00"N)
   ProjNatOriginLongGeoKey: 9.000000 (  9d 0' 0.00"E)
   ProjScaleAtNatOriginGeoKey: 0.999600
   ProjFalseEastingGeoKey: 500000.000000 m
   ProjFalseNorthingGeoKey: 0.000000 m
GCS: 4326/WGS 84
Datum: 6326/World Geodetic System 1984
Ellipsoid: 7030/WGS 84 (6378137.00,6356752.31)
Prime Meridian: 8901/Greenwich (0.000000/  0d 0' 0.00"E)
Projection Linear Units: 9001/metre (1.000000m)

Corner Coordinates:
Upper Left    (  676660.573, 4730184.770)  ( 11d 9'25.27"E, 42d42'13.87"N)
Lower Left    (  676660.573, 4696588.270)  ( 11d 8'47.86"E, 42d24' 5.41"N)
Upper Right   (  685665.653, 4730184.770)  ( 11d16' 0.80"E, 42d42' 6.23"N)
Lower Right   (  685665.653, 4696588.270)  ( 11d15'21.49"E, 42d23'57.85"N)
Center        (  681163.113, 4713386.520)  ( 11d12'23.79"E, 42d33' 5.89"N)
$

And for the same image (yet again, it's a GeoTIFF image) listgeo is reporting that:

this raster adopts a planar, metric WGS 84 / UTM zone 32N Reference System (aka SRID 32632).
the overall extension spans between 676,660.573 and 685,665.653 along the X axis; and between 4,696,588.270 and 4,730,184.770 along the Y axis.
each pixel exactly corresponds to 4.06 meters measured over the terrain, and all pixels have an exactly square shape.

third and last example

$ tiffinfo ETOPO1_Ice_g.tif
TIFF Directory at offset 0x1bf23534 (468858164)
  Image Width: 21601 Image Length: 10801
  Tile Width: 64 Tile Length: 64
  Resolution: 1, 1 (unitless)
  Bits/Sample: 16
  Sample Format: signed integer
  Compression Scheme: None
  Photometric Interpretation: min-is-black
  Orientation: row 0 top, col 0 lhs
  Samples/Pixel: 1
  Planar Configuration: single image plane
  Software: IMAGINE TIFF Support
Copyright 1991 - 1999 by ERDAS, Inc. All Rights Reserved
@(#)$RCSfile: etif.c $ $Revision: 1.10.1.9.1.9.2.11 $ $Date: 2004/09/15 18:42:01
EDT $
  Tag 33550: 0.016667,0.016667,0.000000
  Tag 33922: 0.000000,0.000000,0.000000,-180.008333,90.008333,0.000000
  Tag 34735: 1,1,0,5,1024,0,1,2,1025,0,1,1,1026,34737,271,0,2048,0,1,4326,2054,0
,1,9102
  Tag 34737: IMAGINE GeoTIFF Support
Copyright 1991 - 2005 by Leica Geosystems Geospatial Imaging, LLC. All Rights Re
served
@(#)$RCSfile: egtf.c $ IMAGINE 9.0 $Revision: 10.0 $ $Date: 2005/07/26 15:10:00
EST $
Projection Name = Geographic (Lat/Lon)
Units = degrees
GeoTIFF Units = dd|
$

In this last example tiffinfo is reporting that:

this raster does contain 21,601 x 10,801 pixels.
there is just a single band of INT16 pixels (Sample Format: signed integer).
a Photometric Interpretation of the Grayscale type is someway suggested (min-is-black).
the image is not compressed.
the internal layout of this TIFF is of the tiled type (Tile Width and Tile Length), and each tile contains 64 x 64 pixels.
in this case the single image plane is practically irrelevant, because there is simply one single band.

$ listgeo ETOPO1_Ice_g.tif
Geotiff_Information:
   Version: 1
   Key_Revision: 1.0
   Tagged_Information:
      ModelTiepointTag (2,3):
         0                 0                 0
         -180.008333333335 90.008333369335   0
      ModelPixelScaleTag (1,3):
         0.01666666667     0.01666666667     0
      End_Of_Tags.
   Keyed_Information:
      GTModelTypeGeoKey (Short,1): ModelTypeGeographic
      GTRasterTypeGeoKey (Short,1): RasterPixelIsArea
      GTCitationGeoKey (Ascii,271): "IMAGINE GeoTIFF Support\nCopyright 1991 - 2
005 by Leica Geosystems Geospatial Imaging, LLC. All Rights Reserved\n@(#)$RCSfi
le: egtf.c $ IMAGINE 9.0 $Revision: 10.0 $ $Date: 2005/07/26 15:10:00 EST $\nPro
jection Name = Geographic (Lat/Lon)\nUnits = degrees\nGeoTIFF Units = dd"
      GeographicTypeGeoKey (Short,1): GCS_WGS_84
      GeogAngularUnitsGeoKey (Short,1): Angular_Degree
      End_Of_Keys.
   End_Of_Geotiff.

GCS: 4326/WGS 84
Datum: 6326/World Geodetic System 1984
Ellipsoid: 7030/WGS 84 (6378137.00,6356752.31)
Prime Meridian: 8901/Greenwich (0.000000/  0d 0' 0.00"E)

Corner Coordinates:
Upper Left    (180d 0'30.00"W, 90d 0'30.00"N)
Lower Left    (180d 0'30.00"W, 90d 0'30.00"S)
Upper Right   (180d 0'30.00"E, 90d 0'30.00"N)
Lower Right   (180d 0'30.00"E, 90d 0'30.00"S)
Center        (  0d 0' 0.00"E,  0d 0' 0.00"N)
$

As reported by listgeo this is another GeoTIFF adopting the WGS 84 Reference System (aka SRID 4326), coordinates are of the long/lat type, and the declared extent covers all the World.

Caveats
Many TIFF rasters have a really huge size (many hundredth MB): this could easily cause severe troubles to many naive not professional viewers (this including intolerable slowness and even a possible crash). As we've seen in the previous examples, many TIFF rasters adopt an odd and unusual internal layout; so many common viewers could mistakenly show an apparently empty, blank image. Last but not least: many widespread image editors aren't minimally aware about the GeoTIFF extensions, thus wrongly handling the raster just as it was an ordinary TIFF. e.g. any attempt to edit and then save a GeoTIFF using the very popular GIMP will cause all georeferencing informations to be irremediably lost.

Caveats

Many TIFF rasters have a really huge size (many hundredth MB): this could easily cause severe troubles to many naive not professional viewers (this including intolerable slowness and even a possible crash).
As we've seen in the previous examples, many TIFF rasters adopt an odd and unusual internal layout; so many common viewers could mistakenly show an apparently empty, blank image.
Last but not least: many widespread image editors aren't minimally aware about the GeoTIFF extensions, thus wrongly handling the raster just as it was an ordinary TIFF. e.g. any attempt to edit and then save a GeoTIFF using the very popular GIMP will cause all georeferencing informations to be irremediably lost.

what's a WorldFile ? and how it works ?

As we've already seen in the preliminary introduction, an accompanying WorldFile could be eventually deployed in order to georeference a raster image.

0.20000000
0.00000000
0.00000000
-0.20000000
656750.059946
4848004.988684

A WorldFile simply is a plain text file presenting exactly six lines, and each line is expected to just contain a decimal number:
- line #1 corresponds to the Pixel horizontal resolution (measured in map units).
- line #2 corresponds to an eventual rotation (x-axis)
- line #3 y-axis rotation.
  Please note: RasterLite2 will never take in consideration these rotation values.
- line #4 corresponds to the Pixel vertical resolution, and is usually negative because map (cartesian) coordinates conventionally grow from bottom to top, whilst image scanlines are often progressively numbered from top to bottom.
- line #5 identifies an X coordinate (in the map Reference System).
- line #6 identifies an Y coordinate: both coordinates are expected to specify the tie-point, i.e. the map point corresponding to the upper-left corner of the raster.
Any WorldFile is always expected to present exactly the same identical file-name declared by the corresponding raster file, but presenting a different file-extension accordingly to the following conventional rules:
- WorldFiles associated to TIFF rasters are expected to declare a .tfw extension.
- a .jgw extension is expected for JPEG images.

Caveats
Any WorldFile simply is a plain text file; you can easily read and eventually modify any WorldFile simply using any normal text editor. You can eventually adjust a malformed WorldFile, and you could even create one of your own from scratch in the easiest way. You can safely edit the raster using any common image editor (e.g. the GIMP), and such an action will never corrupt the associated georeference (because in this case you'll have a completely separate file). Handling two different files simply joined by a common name and only distinguished by conventional extension is not really a robust solution: you could easily experience some trouble when using a case sensitive file-system, as e.g. on Linux platforms. Please note well: the WorldFile format specifications never support the explicit declaration of the intended Reference System. So you are always required to indirectly identify the most appropriate SRID.

Caveats

Any WorldFile simply is a plain text file; you can easily read and eventually modify any WorldFile simply using any normal text editor.
You can eventually adjust a malformed WorldFile, and you could even create one of your own from scratch in the easiest way.
You can safely edit the raster using any common image editor (e.g. the GIMP), and such an action will never corrupt the associated georeference (because in this case you'll have a completely separate file).
Handling two different files simply joined by a common name and only distinguished by conventional extension is not really a robust solution: you could easily experience some trouble when using a case sensitive file-system, as e.g. on Linux platforms.
Please note well: the WorldFile format specifications never support the explicit declaration of the intended Reference System.
So you are always required to indirectly identify the most appropriate SRID.

about ASCII Grids

An ASCII Grid too simply is a plain text file.

ncols 8404
nrows 8563
xllcorner 1690692
yllcorner 4779241
cellsize 10
NODATA_value -99.00
 246.97 247.93 248.89 249.85 ...........

the first six lines of each ASCII Grid have a very special meaning, and represent the header fully specifying the intended georeference:
- line #1: qualified by the ncols keyword, and expected to declare the number of pixels for each scanline.
- line #2: qualified by the nrows keyword, and expected to declare the total count of scanlines.
- line #3: qualified by the xllcorner or xllcenter keywords, and expected to declare an X map coordinate.
- line #4: qualified by the yllcorner or yllcenter keyword, and expected to declare an Y map coordinate.
  Both X and Y coordinates define the tie-point, i.e. the map point corresponding to the lower-left corner of the raster.
- line #5: qualified by the cellsize keyword, and corresponding to the Pixel horizontal and vertical resolution (measured in map units).
  Please note: ASCII Grid only supports square pixels.
- line #6: qualified by the NODATA_value keyword, and corresponding to a special pixel value assumed to represent the complete absence of any meaningful value (more or less kind-of a NULL value).
any subsequent line is expected to contain exactly ncols numbers, separated one by the other by a white-space.
and exactly nrows lines are expected to be found before the EOF.

Caveats
You can easily read and eventually modify any ASCII Grid simply using a text editor. Please note: anyway ASCII Grids are usually very huge: many naive text editors could easily be unable to correctly handle these big files in an efficient way. Using the well known vi is warmly suggested when viewing/editing any ASCII Grid. You can safely edit the raster using any common image editor (e.g. the GIMP), and such an action will never corrupt the associated georeference (because in this case you'll have a completely separate file). Handling two different files simply joined by a common name and only distinguished by conventional extension is not really a robust solution: you could easily experience some trouble when using a case sensitive file-system, as e.g. on Linux platforms. Please note well: the ASCII Grid format specifications never support the explicit declaration of the intended Reference System. So you are always required to indirectly identify the most appropriate SRID. Please note well #2: anyway the ASCII Grid header nicely supports a very useful *NoData* declaration, which is completely ignored by the GeoTIFF specifications; nobody is perfect.

Caveats

You can easily read and eventually modify any ASCII Grid simply using a text editor.
Please note: anyway ASCII Grids are usually very huge: many naive text editors could easily be unable to correctly handle these big files in an efficient way. Using the well known vi is warmly suggested when viewing/editing any ASCII Grid.
You can safely edit the raster using any common image editor (e.g. the GIMP), and such an action will never corrupt the associated georeference (because in this case you'll have a completely separate file).
Handling two different files simply joined by a common name and only distinguished by conventional extension is not really a robust solution: you could easily experience some trouble when using a case sensitive file-system, as e.g. on Linux platforms.
Please note well: the ASCII Grid format specifications never support the explicit declaration of the intended Reference System.
So you are always required to indirectly identify the most appropriate SRID.
Please note well #2: anyway the ASCII Grid header nicely supports a very useful NoData declaration, which is completely ignored by the GeoTIFF specifications; nobody is perfect.

about GDAL

For any people seriously interested into rasters the open source GDAL library and related tools is an absolute must.
GDAL supports many zillion formats and options, and it's surely worth to be taken in serious consideration; and it's easily available on the most commonly used platforms, this obviously including Windows, Linux and MacOsX.

Back to RasterLite2 Tutorials index