Gdal source code analysis (9) gdal System Architecture

The gdal library contains the reading and writing of raster data, the reading and writing of vector data, and the related algorithms of raster and vector data. The following describes the architecture of grid data and vector data in gdal. I am very bad at English. I cannot understand some of the items I have written. If I don't understand, I can read English.

1. gdal System Architecture

See gdal official document: http://www.gdal.org/gdal_datamodel.html.

Gdal uses abstract data model to parse the supported data formats. abstract data models include datasets and coordinate systems ), affine geotransform, GCPs, metadata, subdatasets domain, image_structure domain, and RPC
Domain), XML domain (XML: domains), raster band, color table, and overviews ).

1. Dataset)

A dataset is composed of a grid band and related information (For details, refer to the gdaldataset class). All the bands in a specified dataset share the same size (number of rows and number of columns ); datasets define geographic coordinates, projections, and other information for all bands. datasets also contain metadata that is a string list consisting of strings (names: values.

Gdal dataset is implemented based on the description of OpenGIS grid data.

2. Coordinate System (coordinatesystem)

The coordinate system in the dataset is based on the WKT (wellknown text) string format of OpenGIS. It contains the following content:

• Coordinate System name
• Geographic coordinate system name
• Geolevel
• Top body name, long half axis and flat rate
• The name of the central meridian and Its offset from the primary meridian
• Projection Method (for example, horizontal mocato)
• Projection parameter list (for example, central longitude)
• Unit name and conversion coefficient between the unit name and meter or radian
• Name and coordinate Sequence
• The epsg code corresponding to the preceding items

For more information about WKT coordinate definition and related information of OpenGIS, see osr_tutorial. Functions can be used to obtain coordinates.Gdaldataset: getprojectionref ()If the return value of this function is "", the image does not have a geographical coordinate system.

1. Affine geotransform)

The gdal dataset has two ways to represent the relationship between the grid row and column numbers and geographical coordinates. The first one is also the most commonly used, it is represented by an affine transform (the other is a GCP point ).

The ry transform consists of six parameters, which can be obtained using the gdaldataset: getgeotransform () function. The Conversion Relationship Between the row and column numbers and the geographical space is as follows:

    Xgeo = GT(0) + Xpixel*GT(1) + Yline*GT(2)

    Ygeo = GT(3) + Xpixel*GT(4) + Yline*GT(5)

In an image up the North, the values of GT (2) and gt (4) are 0, GT (1) indicates the width of the image, and gt (5) indicates the height of the image. Point (GT (0), GT (3) indicates the horizontal and vertical coordinate value in the upper left corner of the image.

It is worth noting that, in the row and column number coordinate system, the coordinates of the image (0.0, 0.0) are in the upper left corner of the image, and the coordinates (number of pixel width, number of pixel height) represent the coordinates in the lower right corner of the image. In the upper left corner of the image, the coordinate of the central point of the image is (0.5, 0.5 ).

2. gc (GCPs)

A dataset may contain a series of control points to determine the geographic reference coordinates of an image. All control points are in the same coordinate system (you can use the gdaldataset: getgcpprojection () function to obtain the coordinate system). Each GCP (represented by the gdal_gcp class) includes the following content:

typedef struct{    char    *pszId;     char    *pszInfo;    double  dfGCPPixel;    double  dfGCPLine;    double  dfGCPX;    double  dfGCPY;    double  dfGCPZ;} GDAL_GCP;
The pszid string represents a unique string that is used to despise the specific GCP points in the current dataset (generally, it may be composed of numbers, but not all ). Pszinfo is usually an empty string, but it can be used to store the text information customized to describe GCP. It is likely to contain some status information of GCP, such as the retrieval time.
The coordinate (pixel, line) indicates the position of GCP in the image. The coordinate (x, y, z) indicates the position in the geographic reference coordinate system. Generally, the Z value is 0.
The gdal data model does not contain the conversion equation composed of GCP points, which is often processed in applications. Generally, one to five polynomials are used for conversion.
Generally, a dataset includes an affine geographic coordinate transformation. GCP points may exist. Sometimes none of them exist.
3. Metadata (metadata)
Gdal metadata is a list of point pairs that use a name/value for the secondary format and data specified by the application. The name must be effective (without spaces or other special characters ). The value can have any length and can include anything except null values (ASCII 0 values ).
Metadata cannot process too much data in the system. If the metadata exceeds kb, performance will decrease.
Metadata in some common formats can be supported. For example, the tiff Driver returns some tag information as metadata. For example, the date/time format is as follows:
Export tag_datetime = 1999: 05: 11 11:29:56
Metadata can be split into different fields by name group. The default domain has no name, for example (null or ""). Some special fields are used for special purposes.
The following metadata items are defined in the default domain:
 
 

  
  
Area_or_point: It can be "area" or "point". The default value is area. A pixel value indicates the pixel value of the central pixel or the sample value of the pixel center. However, this does not affect the geographic reference information of the entire region.
  
  
Nodata_values: nodata value. This value is a series of pixel values separated by spaces. The number is the same as the number of bands. This method is used to match a nodata value in all bands. This metadata is not widely used in data drives, algorithms, or toolsets.
  
  
Matrix_representation: this value is used to represent the polarization SAR dataset, including the data represented by a matrix. The matrix can be represented by the following values: 
   
 
    
Scattering
 
    
Symmetrized_scattering symmetric Scattering
 
    
Covariance
 
    
Symmetrized_covariance symmetric Covariance
 
    
Coherency coherence
 
    
Symmetrized_coherency symmetric coherence
 
    
Kennaugh
 
    
Symmetrized_kennaugh
 
   
  
  
Polarmetric_interp: this metadata item is used to define the raster band of the multi-band polarization SAR data. The specified matrix indicates the data in this band. A dataset is a scattering matrix. For example, the acceptable values of this metadata include HH, HV, HH, and vv. When a dataset is a covariance matrix, the metadata is one of covariance_11, covariance_22, covariance_33, covariance_12, covariance_13, and covariance_23 (because the matrix itself is a Hermitian matrix, that is, all data is used to represent this matrix ).
 
 
4. subdatasets domain)
The subdataset domain contains a list of subdatasets. It is usually used to store multiple files in one file (such as HDF and nitf formats). For example, a file in nitf format obtains information about the subdataset as follows:
Subdataset_1_name = nitf_im: 0: multi_1b.ntf
Subdataset_includesc = image 1 of multi_1b.ntf
Subdataset_2_name = nitf_im: 1: multi_1b.ntf
Subdataset_2_desc = Image 2 of multi_1b.ntf
Subdataset_3_name = nitf_im: 2: multi_1b.ntf
Subdataset_3_desc = image 3 of multi_1b.ntf
Subdataset_4_name = nitf_im: 3: multi_1b.ntf
Subdataset_4_desc = Image 4 of multi_1b.ntf
Subdataset_5_name = nitf_im: 4: multi_1b.ntf
Subdataset_5_desc = image 5 of multi_1b.ntf
A string containing _ name. You can use the gdalopen () function to access sub-files. The _ DESC string is used to conveniently display the file to be selected.
5. Image structure domain)
The metadata of the default domain is used to describe information about the image, which is not stored in a special way on the disk. This means that when the metadata information is copied to a new image, it will exist in the new image in an appropriate way. In addition, some information is closely related to the image format. To prevent the information from being copied when being written to a new image, the information is stored in a special domain called image_structure. Normally, what is stored here is not written into the new image.
Objectives: The following items are defined in the image_structure domain.
 
 

  
  
Compression: the compression method is used to specify the compression method of the dataset or band. There is no fixed compression type name, but a specified format. If the compression method is specified, this compression method will be used during creation.
  
  
Nbits: the number of actually stored bits in the current band or the current dataset. This value is usually used only for non-standard data types. For example, 1-bit data in a TIFF image is represented by gdt_byte in gdal.
  
  
Interleave: this parameter can only be used in a data set to indicate the interval between one pixel, one row, and one band. It can be used as a prompt for reading data.
  
  
Pixeltype: This value will appear in a gdt_byte band (or corresponding dataset, the signedbyte value is used to indicate that the value of the unsigned byte between 128 and 255 should be converted to-128 to-1.
 
 
6. RPC domain (rpcdomain)
The RPC metadata domain stores the coefficients of the rational function model, which represents the transformation relationship between the row and column numbers of the image and the spatial reference location. The model is defined as follows:
· Err_bias: offset error, which indicates the deviation of all vertices on the image on the horizontal axis.-1.0 indicates unknown.
· Err_rand: random error. It indicates the random error of all points in the image on the horizontal axis.-1.0 indicates the unknown.
· Line_off: Row offset
· Samp_off: column offset
· Lat_off: latitude offset
· Long_off: longitude offset
· Height_off: elevation offset
· Line_scale: Row scaling ratio
· Samp_scale: column scaling ratio
· Lat_scale: latitude scaling ratio
· Long_scale: longitude scaling ratio
· Height_scale: Elevation scaling ratio
· Line_num_coeff (1-20): Row molecular coefficient, a total of 20 (separated by spaces)
· Line_den_coeff (1-20): the row denominator coefficient, a total of 20 (separated by spaces)
· Samp_num_coeff (1-20): column molecular coefficient, a total of 20 (separated by spaces)
· Samp_den_coeff (1-20): column denominator coefficient, a total of 20 (separated by spaces)
These contents are from the RPC documentation (http://geotiff.maptools.org/rpc_prop.html) of geotiff ).
7. xml domain (XML: domains)
Any prefix is a string of "XML:", but not a name/value type. It is a simple long string in XML format.
8. Raster band)
A grid band is represented by the gdalrasterband class in gdal. It represents a raster band, channel, or layer. The band cannot be used to represent the entire image completely. For example, a 24-bit RGB image contains three bands: Red, green, and blue.
The raster band contains the following attributes:
· The image width and height are the same as those defined in the dataset, if the band is a full-resolution band. (The gdalrasterband can also represent the pyramid band. If it is the pyramid band, the width and height in it are different from the width and height of the image ).
· Data Type (gdaldatatype ). It should be one of byte, uint16, int16, uint32, int32, float32, float64, and cint16, cint32, cfloat32, and cfloat64.
· Block size. Block is the most efficient way to read data. block data is the size of a block. For most images, a block is a row.
· Name/value metadata pair, a member of the format and dataset, but the information contained may be band-specific.
· An optional band description string.
· An optional image meta value used to describe nodata values.
· An optional nodata value indicates the mask band or, in some cases, acts as a transparent channel.
· List of optional category names (used for classification charts)
· Optional maximum and minimum values.
· Optional offset and zoom ratio, used to transform the pixel value of the image, such as converting the height to the meter.
· Image unit name, optional. For example, it can be used to indicate the elevation of elevation data.
· The color information of the band, which is one of the following nominal values:
O gci_undefined: Default Value, unknown
O gci_grayindex: grayscale image
O gci_paletteindex: Color Table Image
O gci_redband: R part of the rgba Image
O gci_greenband: G part of the rgba Image
O gci_blueband: Part B of the rgba Image
O gci_alphaband: Alpha part of the rgba Image
O gci_hueband: HLS image tones
O gci_saturationband: HLS image saturation
O gci_lightnessband: brightness of the HLS Image
O gci_cyanband: The cyan part of the CMYK Image
O gci_magentaband: The red part of the CMYK Image
O gci_yellowband: yellow part of CMYK Image
O gci_blackband: The black part of the CMYK image.
· Color table, which is described in more detail below.
· If the pyramid is available, it contains information about the pyramid.
9. Color Table)
The definition of the color table is as follows:
typedef struct{    /- gray, red, cyan or hue-/    short      c1;    /- green, magenta, orlightness -/       short      c2;    /- blue, yellow, orsaturation -/    short      c3;    /- alpha or blackband -/    short      c4;     } GDALColorEntry;
A color table is usually a value of the color palette. For C1/C2/C3/C4 values, different color palette values have different meanings. For specific meanings, see:
L gpi_gray: Uses C1 to represent the gray value.
L gpi_rgb: C1 indicates red, C2 indicates green, C3 indicates blue, and C4 indicates alpha channel.
L gpi_cmyk: C1 indicates cyan, C2 indicates Magenta, C3 indicates yellow, and C4 indicates black.
L gpi_hls: C1 indicates the color tone, C2 indicates the brightness, and C3 indicates the saturation.
In the color table, the object meta value is represented by the color in the color table, and the value in the color table increases from 0.
10. Overviews)
A single band may have no or many quick views. Each quick view is a gdalrasterband. The size of a thumbnail is different from that of the lower-level raster. However, the area of the quick view is the same as that of the entire image.
Quick View is used to quickly display images. Full-resolution images are used for downsampling.
The hasarbitraryoverviews function can be used to return true, which indicates that the quick view of any resolution can be quickly read. This function is mainly used in some FFT-encoded images (this sentence is a bit awkward, read the original English text by yourself ).
11. gdal core Class Structure Design
The core class structure design of gdal:
The classes are described as follows:
Gdalmajorobject class: object with metadata.
Gdalddataset class: it is usually a collection of associated raster bands and metadata of these bands extracted from a grid file. gdalddataset is also responsible for geolocation (georeferencingtransform) and coordinate system definition of all raster bands.
Gdaldriver class: File Format Driver Class. gdal creates an object of this class for each supported file format to manage the file format.
Gdaldrivermanager class: File Format driver management class, used to manage gdaldriver class.
Ii. OGR architecture 1. OGR Architecture
OGR includes the following parts:
Geometry: Class geometry (including ogrgeometry and other classes) encapsulates the Vector Data Model of OpenGIS, and provides some geometric operations, WKB (well knows binary) and WKT (well known text) format conversion and spatial reference system (projection ).
Spatial Reference: Class ogrspatialreference encapsulates the definition of projection and datum.
Feature: Class ogrfeature encapsulates a complete feature definition. A complete feature includes a series of attributes of a geometry and geometry.
Feature Definition: Class ogrfeaturedefn contains the attributes, types, names, and default space Reference Systems of feature. An ogrfeaturedefn Object usually corresponds to a layer.
Layer: Class ogrlayer is an abstract base class that represents a layer of elements (feature) in the data source class ogrdatasource ).
Data source: Class ogrdatasource is an abstract base class that represents a file or database containing an ogrlayer object.
Drivers: The ogrsfdriver class corresponds to each supported Vector file format. Class ogrsfdriver is registered and managed by class ogrsfdriverregistrar.
2. OGR geometry model
The geometry model of OGR is built on the Simple Element Data Model of OpenGIS. As shown in:
Figure-geometry model diagram of OGR
The diagram of the Simple Element Data Model of OpenGIS is as follows:
Figure-Simple Element Data Model of OpenGIS
From the comparison of the above two figures, we can clearly see that the OGR geometry model strictly complies with the simple element data standards of OpenGIS. The geometry model of OGR is not only consistent with the simple element data model of OpenGIS in the inheritance system, but also close to it in the function interface. The basic method for obtaining geometry object information is as follows: dimension () geometrytype (), SRID (), envelope (), astext (), and boundary () wait until the method used to determine the unknown spatial relationship is equals (anothergeometry: geometry), disjoint (anothergeometry: geometry ),
Intersects (anothergeometry: geometry) and touches (anothergeometry: geometry) all comply with their standards.
The OGR library will be described later. Here is a brief description.