Always a combination of projection and grid specification, i.e., grids laid out on top of 2D projected space.
A special case is the “Geographic Grid” where the projection is an “Identity” transformation from lon/lat to X/Y (as lon/lat), and X, Y are laid out in units of degrees. This is also sometimes referred to as the no-projection (not projected) grid.
GCTP - has the longest heritage dating back to the 1970s
Established to support the development of computational projection software
OGC WKT (Well-Known-Text) is close behind in historical significance,
but is the most complex and difficult to understand (design by committee)
Proj: is the newer, more concise,
and still evolving standard. - but Proj is not considered as complete or as well-defined a standard as OGC-WKT!
CF - each variable has a grid-mapping reference - to a grid-mapping variable (projection info)
GeoTIFF uses OGC Key Set (somewhat complex, difficult to find key values, see below)
HegService uses its own Data-Access/EGI/ESI set of names and parameters. See ESI API documentation: EGI-ESI API Schema
——
HDF-EOS (and HDFEOS-5) uses GCTP
GDAL uses Proj and/or WKT in its command line parameters.
HEG (stand alone) uses HDF-EOS & HDFEOS-5, which uses GCTP
A fully specified grid for geo-location is a combination of projection (or "Geographic")
- and a layout of rows and columns, with specific size, location, and resolution.
- typically defined by corner points, resolution and size (rows, columns, height, width).
- Here, that layout is called the grid specification.
GeoTIFF - uses:
Note Also - Cell-Geometry:
- Pixel-as-Point (center-aligned) or
- Pixel-as-Area (corner/edge-aligned)
Note two common but opposite perspectives on the array of science values
HDF-EOS (actually defined by using minor features of GCTP, as noted above)
uses UL,LR Corner-Points + dimension-array sizes
(resolution implicit, calculated, cell-center values are assumed)
Note HEG often calculates resolution first, then calculates dimension-sizes, then adjusts lower-right corner-point to fit integral number of grid-cells.
CF uses dimension-scales
GDAL uses GeoTransform (Corner-Points + resolution) in library functions.
Roughly equivalent to Affine Matrix (scale, offset, rotation, used in 3D to 2D display calculations)
GDAL also has dimension-array sizes and may have corner-points from source meta-data.
(Affine matrix uses matrix math to convert (i, j) into (X, Y)
and implicitly, inverse calculations as well)
(An Affine matrix is somewhat overkill, as it also applies 3D rotation to calculations,
Rotation parameters typically (but not always) set to zero for geo-transform purposes,
Affine matrices are commonly used for 3D perspective transformation, 3D to 2D,
They are an aspect of linear algebra mathematics,
Such "linear" transformations are inadequate to fully address geographic projection transformations).
Not standard but potential CF-ish approach:
——
GeoTIFF OGC Key Set for Projection:
(Discovery via listgeo and tiffinfo commands)
GTModelTypeGeoKey (Short,1): ModelTypeProjected
GTRasterTypeGeoKey (Short,1): RasterPixeIsArea
GTCitationGeoKey (Ascii,64): "Lambert Azimuthal Equal Area - North Polar Projection - (WGS84)"
GeographicTypeGeoKey (Short,1): GCS_WGS_84
GeogGeodeticDatumGeoKey (Short,1): Datum_WGS84
GeogLinearUnitsGeoKey (Short,1): Linear_Meter
GeogAngularUnitsGeoKey (Short,1): Angular_Degree
GeogEllipsoidGeoKey (Short,1): Ellipse_WGS_84
GeogSemiMajorAxisGeoKey (Double,1): 6378137
GeogSemiMinorAxisGeoKey (Double,1): 6356752.31424
ProjectedCSTypeGeoKey (Short,1): User-Defined
ProjectionGeoKey (Short,1): User-Defined
ProjCoordTransGeoKey (Short,1): CT_LambertAzimEqualArea
ProjLinearUnitsGeoKey (Short,1): Linear_Meter
ProjLinearUnitSizeGeoKey (Double,1): 1
ProjNatOriginLongGeoKey (Double,1): 0
ProjFalseOriginLongGeoKey (Double,1): 0
ProjCenterLongGeoKey (Double,1): 0
ProjCenterLatGeoKey (Double,1): 90