在维护一段代码时看到前任程序员写的获取栅格数据的CellSize的功能，竟然在知道GDAL的情况下去调用AE的接口来解算，觉得费解。

原来的思路是使用AE的Raster对象读取出Raster的文件大小和真实投影坐标对构造的矩形外框，再来算每个cell的长宽，觉得实在无语。

于是研究了下GDAL怎么获取到一些数据基本信息(Metadata)的。

搬运一下GDAL官方对其数据模型的Metadata的描述：

GDAL metadata is auxiliary format and application specific textual data kept as a list of name/value pairs. The names are required to be well behaved tokens (no spaces, or odd characters). The values can be of any length, and contain anything except an embedded null (ASCII zero).

The metadata handling system is not well tuned to handling very large bodies of metadata. Handling of more than 100K of metadata for a dataset is likely to lead to performance degradation.

Metadata is split into named groups called domains, with the default domain having no name (NULL or ""). Some specific domains exist for special purposes. Note that currently there is no way to enumerate all the domains available for a given object, but applications can "test" for any domains they know how to interpret.

这里需要注意一下描述中我标红的部分，意思是GDAL本身确实提供了非常丰富的Metadata，但是不是所有数据都有这些内容。另外第一段标红的部分里讲，GDAL在存储较大的metadata时（100k以上）会有一定性能问题。当然100k已经很多内容了。

这里的metadata由api中的 Dataset.GetMetadata(String) 方法获取，得到的是一个字符串数组对象。按照纯粹的理论而言，这个数组里的内容是非常丰富的，包括以下部分(复制自GDAL官网)：

The following metadata items have well defined semantics in the default domain:

• AREA_OR_POINT: May be either "Area" (the default) or "Point". Indicates whether a pixel value should be assumed to represent a sampling over the region of the pixel or a point sample at the center of the pixel. This is not intended to influence interpretation of georeferencing which remains area oriented.
• NODATA_VALUES: The value is a list of space separated pixel values matching the number of bands in the dataset that can be collectively used to identify pixels that are nodata in the dataset. With this style of nodata a pixel is considered nodata in all bands if and only if all bands match the corresponding value in the NODATA_VALUES tuple. This metadata is not widely honoured by GDAL drivers, algorithms or utilities at this time.
• MATRIX_REPRESENTATION: This value, used for Polarimetric SAR datasets, contains the matrix representation that this data is provided in. The following are acceptable values:
  • SCATTERING
  • SYMMETRIZED_SCATTERING
  • COVARIANCE
  • SYMMETRIZED_COVARIANCE
  • COHERENCY
  • SYMMETRIZED_COHERENCY
  • KENNAUGH
  • SYMMETRIZED_KENNAUGH
• POLARIMETRIC_INTERP: This metadata item is defined for Raster Bands for polarimetric SAR data. This indicates which entry in the specified matrix representation of the data this band represents. For a dataset provided as a scattering matrix, for example, acceptable values for this metadata item are HH, HV, VH, VV. When the dataset is a covariance matrix, for example, this metadata item will be one of Covariance_11, Covariance_22, Covariance_33, Covariance_12, Covariance_13, Covariance_23 (since the matrix itself is a hermitian matrix, that is all the data that is required to describe the matrix).
• METADATATYPE: If IMAGERY Domain present, the item consist the reader which processed the metadata. Now present such readers:
  • DG: DigitalGlobe imagery metadata
  • GE: GeoEye (or formally SpaceImaging) imagery metadata
  • OV: OrbView imagery metadata
  • DIMAP: Pleiades imagery metadata
  • MSP: Resurs DK-1 imagery metadata
  • ODL: Landsat imagery metadata

SUBDATASETS Domain

The SUBDATASETS domain holds a list of child datasets. Normally this is used to provide pointers to a list of images stored within a single multi image file.

For example, an NITF with two images might have the following subdataset list.

SUBDATASET_1_NAME=NITF_IM:0:multi_1b.ntf SUBDATASET_1_DESC=Image 1 of multi_1b.ntf SUBDATASET_2_NAME=NITF_IM:1:multi_1b.ntf SUBDATASET_2_DESC=Image 2 of multi_1b.ntf

The value of the _NAME is the string that can be passed to GDALOpen() to access the file. The _DESC value is intended to be a more user friendly string that can be displayed to the user in a selector.

Drivers which support subdatasets advertize the DMD_SUBDATASETS capability. This information is reported when the --format and --formats options are passed to the command line utilities.

Currently, drivers which support subdatasets are: ADRG, ECRGTOC, GEORASTER, GTiff, HDF4, HDF5, netCDF, NITF, NTv2, OGDI, PDF, PostGISRaster, Rasterlite, RPFTOC, RS2, WCS, and WMS.

IMAGE_STRUCTURE Domain

Metadata in the default domain is intended to be related to the image, and not particularly related to the way the image is stored on disk. That is, it is suitable for copying with the dataset when it is copied to a new format. Some information of interest is closely tied to a particular file format and storage mechanism. In order to prevent this getting copied along with datasets it is placed in a special domain called IMAGE_STRUCTURE that should not normally be copied to new formats.

Currently the following items are defined by RFC 14 as having specific semantics in the IMAGE_STRUCTURE domain.

• COMPRESSION: The compression type used for this dataset or band. There is no fixed catalog of compression type names, but where a given format includes a COMPRESSION creation option, the same list of values should be used here as there.
• NBITS: The actual number of bits used for this band, or the bands of this dataset. Normally only present when the number of bits is non-standard for the datatype, such as when a 1 bit TIFF is represented through GDAL as GDT_Byte.
• INTERLEAVE: This only applies on datasets, and the value should be one of PIXEL, LINE or BAND. It can be used as a data access hint.
• PIXELTYPE: This may appear on a GDT_Byte band (or the corresponding dataset) and have the value SIGNEDBYTE to indicate the unsigned byte values between 128 and 255 should be interpreted as being values between -128 and -1 for applications that recognise the SIGNEDBYTE type.

RPC Domain

The RPC metadata domain holds metadata describing the Rational Polynomial Coefficient geometry model for the image if present. This geometry model can be used to transform between pixel/line and georeferenced locations. The items defining the model are:

• ERR_BIAS: Error - Bias. The RMS bias error in meters per horizontal axis of all points in the image (-1.0 if unknown)
• ERR_RAND: Error - Random. RMS random error in meters per horizontal axis of each point in the image (-1.0 if unknown)
• LINE_OFF: Line Offset
• SAMP_OFF: Sample Offset
• LAT_OFF: Geodetic Latitude Offset
• LONG_OFF: Geodetic Longitude Offset
• HEIGHT_OFF: Geodetic Height Offset
• LINE_SCALE: Line Scale
• SAMP_SCALE: Sample Scale
• LAT_SCALE: Geodetic Latitude Scale
• LONG_SCALE: Geodetic Longitude Scale
• HEIGHT_SCALE: Geodetic Height Scale
• LINE_NUM_COEFF (1-20): Line Numerator Coefficients. Twenty coefficients for the polynomial in the Numerator of the rn equation. (space separated)
• LINE_DEN_COEFF (1-20): Line Denominator Coefficients. Twenty coefficients for the polynomial in the Denominator of the rn equation. (space separated)
• SAMP_NUM_COEFF (1-20): Sample Numerator Coefficients. Twenty coefficients for the polynomial in the Numerator of the cn equation. (space separated)
• SAMP_DEN_COEFF (1-20): Sample Denominator Coefficients. Twenty coefficients for the polynomial in the Denominator of the cn equation. (space separated)

These fields are directly derived from the document prospective GeoTIFF RPC document (http://geotiff.maptools.org/rpc_prop.html) which in turn is closely modeled on the NITF RPC00B definition.

The line and pixel offset expressed with LINE_OFF and SAMP_OFF are with respect to the center of the pixel.

IMAGERY Domain (remote sensing)

For satellite or aerial imagery the IMAGERY Domain may be present. It depends on exist special metadata files near the image file. The files at the same directory with image file tested by the set of metadata readers, if files can be processed by the metadata reader, it fill the IMAGERY Domain with the following items:

• SATELLITEID: A satellite or scanner name
• CLOUDCOVER: Cloud coverage. The value between 0 - 100 or 999 if not available
• ACQUISITIONDATETIME: The image acquisition date time in UTC

xml: Domains

Any domain name prefixed with "xml:" is not normal name/value metadata. It is a single XML document stored in one big string.

因为官方的说明只给了这些内容，所以我们大致能知道的是，在GDAL的数据模型中，Metadata是以数组形式存储键值对（Key Value Pairs），形式为【key=value】，且按照不同的Domains来进行分组。

实际上， Dataset.GetMetadata(String)所要求的参数是Domain的名称，而Default Domain则可以以【NULL】或者【“”】进行赋值。

喜闻乐见的是，好像这些信息非常的有价值。

然而悲剧的是，如官方所述，不是所有的数据都完整包含每个键值对。

在我的本地测试里使用的一景Landsat8数据就无法获取到除 【AREA_OR_POINT】以外的Metadata。

所以在本地的代码里目前的写法是使用Linq+三目判定，由于项目暂且仅使用Landsat8数据（除15m全色以外的波段）,故可以直接为无法从Metadata中得到cellSize值时按30m计算。

若是需要做类似的功能，个人建议是使用直接数值计算影像左上角点和右下角点两个Point的投影坐标值后，按得到的距离除以数据的长宽作为CellSize。当然，需要自己考虑是否忽略小数或精确多少位。不使用AE提供的接口是因为创建的COM对象释放困难，且AE的接口一般存在较大开销，在低端功能上能省则省吧。

当然这里还有一些疑问，如栅格数据的CellSize的单位是m还是啥怎么判断，纯数学方式判定会有多大误差等等。

至于如何保证数据有metadata，也需要在进一步研究后回来更新本篇。

PS：以上涉及代码的部分均为C#环境下.

感谢阅读。