"GDAL" talk about GDAL's data model

Gdal is a very good GIS data Operation Library, recently in and intern introduction Gdal simple use, write down the record

This article records the raster data, the code environment is C #

In Gdal, the raster data is roughly a raster data file (. tif/geotiff format) in a dataset, and the various information in this raster is included as attributes in the dataset's object.

Basically, a raster is stored in the Gdal data model based on the band, typically a single-band data is read in Gdal, and the resulting dataset contains only one band object. The Bandcount property is also 1. The multiband data is similar, meaning that the DataSet object in Gdal is similar to the raster dataset discussed in ArcGIS.

The relevant concepts and instructions are handled in the official documentation.

Dataset

A DataSet (represented by the Gdaldataset Class) was an assembly of related raster bands and some information common to them all. In particular the datasets have a concept of the raster size (in pixels and lines) that applies to all the bands. The dataset is also responsible for the georeferencing transform and coordinate system definition of all bands. The dataset itself can also has associated metadata, a list of name/value pairs in string form.

Note that the GDAL dataset, and raster band data model are loosely based on the OpenGIS Grid coverages specification.

The red part is what we should pay attention to in the specific raster data processing, including the size of the data (image length and width), geographical reference and coordinate system definition, metadata of the data and so on. These items are defined in the DataSet object and are valid for all band under this dataset.

The basic content contained in the dataset is discussed in the next step.

It is very important that the data is projected and geo-referenced.

coordinate system for data "coordinate system"

gdal's coordinate system definition is represented by the OpenGIS projection string specification, so when you use the Dataset.getprojection () method, you will find that the return value is a string instead of a projection object. This ensures that in most cases the projection file (information) of the data can be read gdal and interpreted correctly. The coordinate system definition contains the following:

• An overall coordinate system name.
• A geographic coordinate system name.
• A Datum identifier.
• An ellipsoid name, semi-major axis, and inverse flattening.
• A Prime Meridian name and offset from Greenwich.
• A Projection method type (i.e. transverse Mercator).
• A List of projection parameters (i.e. Central_meridian).
• A units name, and conversion factor to meters or radians.
• Names and ordering for the axes.
• Codes for most of the above in terms of predefined coordinate systems from authorities such as EPSG.

Here the feeling needs to mention is that when invoking some Gdal projection conversion method, the required parameters may be written "WKT", familiar with OpenGIS will know that this is OpenGIS WKT coordiante System definitions, that is, the projection string here.

Personal feeling a little more useful tips is a recent colleague reminded, originally used to determine whether the two data is the same coordinate system I directly use Dataset.getprojection () to the resulting string as equals judgment, this is not rigorous. The reason is that some software reads the data and modifies its wkt coordinate system definition (where it is doubtful) to another standard coordinate system definition, so it is recommended to use the Spatialreference object of the OGR library in Gdal.

The code example is as follows (I haven't learned how to insert a code snippet, first)

Because Gdal is a C + + library, so accustomed to all aspects of the C + + style, such as conditional judgment is basically done in 01 ways, need to get used to.

Conversion parameter "Geotransform"

This parameter can generally be called a 6 parameter, because its object is a double[6] array. This parameter is used to calibrate information such as the location of the data, and the relevant method is Dataset.getgeotransform (out double[] args), Dataset.setgeotransform (double[] args)

GDAL datasets has a ways of describing the relationship between raster positions (in pixel/line coordinates) and Georef erenced coordinates. The first, and most commonly used are the affine transform (the other is GCPs).

A specific explanation of the six parameters will be explained in a separate article.

The transformation relationship between a real geographic coordinate and a row of image data is as follows:

Xgeo = GT (0) + XPIXEL*GT (1) + YLINE*GT (2)
Ygeo = GT (3) + XPIXEL*GT (4) + YLINE*GT (5)

"GCPs"

About Gcps don't know much, here is the official explanation for temporary handling

A dataset can has a set of control points relating one or more positions on the raster to georeferenced coordinates. All GCPs share a georeferencing coordinate system (returned by Gdaldataset::getgcpprojection ()). Each GCP (represented as the GDAL_GCP Class) contains the following:

typedef struct{    Char        *pszid;     Char        *pszinfo;    Double      dfgcppixel;    Double      dfgcpline;    Double      dfgcpx;    Double      dfgcpy;    Double      Dfgcpz;} GDAL_GCP;

Meta data "Metadata"

This section please refer to the previous blog about Gdal's metadata

Grid Band "Raster Band"

The band object (Raster Band) is an important object in Gdal. A band object represents a band/channel/layer, so an RGB data in the Gdal model is actually a dataset with 3 bands, where the bands correspond to the Red/green/blue respectively.

The content of the bands will also be explained in detail in another blog post.

"Color Table"

It's almost useless, and it's handled directly.

First look at the structure definition:

A color table consists of zero or more color entries described in C by the following structure:

1typedefstruct2 {3/-Gray, red, cyan or hue-/4      ShortC1;5/-green, magenta, or lightness-/6      ShortC2;7/-blue, yellow, or saturation-/8      ShortC3;9/-Alpha or black band-/Ten      ShortC4;  One} gdalcolorentry;

View Code

The color table also has a palette interpretation value (GDALPALETTEINTERP) which is one of the following values, and Indi Cates how the C1/C2/C3/C4 values of a color entry should be interpreted.

• Gpi_gray:use C1 as Gray scale value.
• Gpi_rgb:use C1 as red, C2 as Green, C3 as blue and C4 as Alpha.
• Gpi_cmyk:use C1 as cyan, C2 as magenta, c3 as yellow and c4 as black.
• Gpi_hls:use C1 as hue, C2 as lightness, and C3 as saturation.

To associate a color with a raster pixel, the pixel value was used as a subscript into the color table. That means the colors is always applied starting at zero and ascending. There is no provision for indicating a pre-scaling mechanism before looking up in the color table.

"Overviews"

According to the official note, this is a band thumbnail.

A band May has zero or more overviews. Each overview are represented as a "free standing" gdalrasterband. The size (in pixels and lines) of the overview would be is different than the underlying raster, but the geographic region cov Ered by overviews are the same as the full resolution band.

The overviews is used to display reduced resolution overviews more quickly than could is done by reading all the full res Olution data and downsampling.

Bands also has a Hasarbitraryoverviews property which is TRUE if the raster can being read at any resolution efficiently but With no distinct overview levels. This applies to some FFT encoded images, or images pulled through gateways (like OGDI) where downsampling can is done Effi ciently at the remote point.

For the last two objects, a later study will be added.

Thanks for watching

"GDAL" talk about GDAL's data model