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.


Projection Specifiecation:
(See wiki on Introductions to Projections for ESDIS/EOS (SDPS): ESDIS-SDPS Earth-Data Projection Introduction)

GCTP - has the longest heritage dating back to the 1970s 
  Established to support the development of computational projection software

  • It notably has a numerically indexed list of projection parameters, with identity established primarily by the sequence number in this list.  Documentation has a table that also matches projection type (name) and the specification of the projection parameters, including a secondary table (index) of numeric parameters and meanings.
  • Note - GCTP also blends Grid operations with projection operations
    • Projection is from (lat, lon) in degrees to (x, y) in projected meters
    • grids overlay rows and columns (i, j) on projected plane (x, y)
    • projection operations: get_xy(lon,lat), get_lonlat(x, y)
    • grid operations: get_rowcol(x,y), get_xy(row, col) -- referencing cell centers for x, y values
      get_rowcol(lon, lat), get_lonlat(row, col)
  • See gctp_include_proj.h, NOAA Rpt - GCTP - 1987.pdf,  HegServiceConstants.java (HegService, ESI codes)

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)

  • uses its own conventions somewhere between WKT & GCTP
  • ( CF allows WKT as an option, it may be necessary for some obscure settings
  •   Proj-string is also an option, but not in the standard settings
  •   Proj attribute is none-the-less strongly recommended as convenient and a de-facto standard )

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

  • Loosely based upon HEG and GCTP, but intended to be more convenient and easier to read.

——

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


Grid Specification

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:

  • Model-Tie-Point (0, 0 indexed corner-point, usually "upper-left")
  • + Model-Pixel-Scale (delta x, y - resolution)

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

    • Image processing, where 0, 0 is upper-left and y values (location in projected meters) decrease in magnitude 
      • delta-y or resolution is a negative value
      • consider a map on the wall with 0, 0 being upper left.
    • mathematics, where 0, 0 is lower-left and y values increase in magnitude
      • delta-y or resolution is a positive value

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

  • Dimension variables with X, Y, or Lat, Lon values (geographic grid) across entire dimension.
  • Explicitly provides corner points (first, last) and dimension-array sizes, and full set of dimension-scale values
  • Resolution implicit, calculated, scale-alignment not specified, be it edge or center


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:

  • GridScaling (similar to GridMapping)
    • Attribute reference and no-value variable - attributes only (scalar or empty array)
    • X_Origin, X_Scale (resolution, scale_increment), scale_alignment
    • Y_Origin, Y_Scale (resolution, scale_increment - can be and often is negative), scale_alignment
    • Rotation
    • Possible - use full Affine matrix (allows for 3D rotation, not often used, but occasionally, I think)
      • x_angle, y_angle, z_angle (alpha, beta, gamma)
      • Or use GeoTransform - 6 numeric values
        but fully qualified/named parameters is likely better documentation.
  • Or, possibly, GridScaling attributes are contained within GridMapping
    (minimal changes but less flexible, slightly confusing)
  • + attributes previously noted as CF extensions?:
    • scale_increment = <resolution>  +/- to accommodate UL & LL images
    • scale_alignment = < edge | center >  # (alias: georef_type, pixel_georef)
        GDAL: Cell Geometry = point(pixel-center) or area (corners)

——

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

  • No labels