[CF-metadata] Horizontal Data Coordinate System Definition [long]

Tue Feb 15 12:20:54 MST 2005

CF gang,

I've been thinking about the UTM thread for the last week, and also 
doing a bit of research.  This UTM issue really brings up the whole 
issue of how to allow for proper georeferencing in NetCDF, in a way that 
easily lets true GIS applications like ArcGIS ingest information from 
the NetCDF file without requiring additional input from the NetCDF file 
provider (or guesses from the GIS user).

FGDC METADATA STANDARD

Since CF is already using FGDC "Content Standard for Digital Geospatial 
Metadata"
<http://www.fgdc.gov/standards/documents/standards/metadata/v2_0698.pdf>
as a guide in choosing the "grid_mapping_name" values and attributes, 
perhaps we could go ahead and basically implement the full standard for 
spatial reference information.  A great one-figure view of this Spatial 
Reference Information in the standard is at:

    http://biology.usgs.gov/fgdc.metadata/version2/meta4.gif

In this figure, the green indicates "mandatory if applicable".  Reading 
the full document reveals that this means that if the data has 
horizontal information, there must be a 
"Horizontal_Coordinate_System_Definition" and if the data has vertical 
information, there must be a "Vertical_Coordinate_System_Definition".

For the horizontal, the choices are "Geographic", "Planar" or "Local" 
coordinate systems.

If we ignore "Local" coordinate systems, which are used only in 
engineering work, (e.g. 200 m east of some known gas rig), we are left 
with "Geographic" (lon,lat coordinates) and "Planar" (projected x,y 
coordinates).   For *both* of these coordinate systems, the 
"Geodetic_Model" specification is required (since it is applicable).

Thus the Horizontal_Coordinate_System_Definition is defined as
[ Geographic | Planar ] + {Geodetic_Model}

GEODETIC MODEL

The Geodetic_Model is defined as:
{Horizontal_Datum_Name}+ Ellipsoid_Name + Semi-major_Axis + 
Denominator_of_Flattening_Ratio

This allows specifying the datum by name if one is being used, such as: 
"North American Datum of 1927", but *requires* that the Ellipsoid_Name 
be given along with the ellipsoid parameters.

PLANAR PROJECTIONS

Planar is defined as:
[Map_Projection | Grid_Coordinate_System | Local_Planar] + 
Planar_Coordinate_Information

Map_Projection is defined as:
Map_Projection_Name + Map_Projection_Parameters

Map_Projection_Name are defined as:
Lambert_Conformal_Conic, Stereographic, etc.

The Grid_Coordinate_System is defined as:
Grid_Coordinate_System_Name + grid system parameters

For Universal_Transverse_Mercator, it is required to specify the 
UTM_Zone_Number. The UTM zones are defined as [1:60] for northern 
hemisphere, and [-60:-1] for southern hemisphere.

So what to do for CF?  Perhaps in addition to "grid_mapping_name" and 
each "grid_mapping_name"s required parameters we could add Ellipsoid 
parameters using FGDC nomenclature, making the "Ellipsoid_Name" 
optional, or refering to a EPSG Ellipsoid, via "Ellipsoid_Name='EPSG:7001';

temperature: grid_mapping="my_mapping"

int my_mapping
  my_mapping: grid_mapping_name = "lambert_conformal_conic";
  my_mapping: standard_parallel = 25.0;
  my_mapping: longitude_of_central_meridian = 265.0;
  my_mapping: latitude_of_projection_origin = 25.0;
  my_mapping: Ellipsoid_Name="Airy 1830";
  my_mapping: Semi-major_Axis=6377563.396;
  my_mapping: Denominator_of_Flattening_Ratio=299.3249646;

to make things easier, we could allow for the use of EPSG codes, as 
these have become quite popular in ArcGIS, WMS servers, etc.  The EPSG 
(The European Petroleum Survey Group) has a database where they assign a 
unique integer code to 42 ellipsoids, 434 datums, 75 projections 
(coordinate operation methods) and 2773 coordinate reference systems 
(combined projection + ellipsoid or datum combinations).

So we could shortcut the above description of the geodetic model by 
using EPSG:7001 to specify the Airy 1830 ellipsoid.

But we could shortcut the whole description of the projection and 
ellipsoid for well-known coordinate reference systems.  For example, 
EPSG assigns a number to each zone in the coordinate system  (UTM + 
WGS84 ellipsoid)

Thus specifying "EPSG:32619" means WGS84/UTM Zone 19N, and *completely 
specifies* the relationship between x,y in meters and lon,lat in 
degrees, without the need to explicitly describe the geoid parameters, 
the projection, and the projection parameters specific to this UTM zone.

HANDLING OF UTM

Also, I guess I'm reversing my position on having UTM as a separate 
"grid_mapping_name", even though it is just a subset of Transverse 
Mercator.   So we could have:

temperature: grid_mapping="my_mapping"

int my_mapping
  my_mapping: grid_mapping_name = "Universal Transverse Mercator";
  my_mapping: UTM_Zone_Number = 33;
  my_mapping: Ellipsoid_Name="WGS 84";
  my_mapping: Semi-major_Axis=6378137;
  my_mapping: Denominator_of_Flattening_Ratio=298.257223563;

and also

int my_mapping
  my_mapping: grid_mapping_name = "Universal Transverse Mercator";
  my_mapping: UTM_Zone_Number = 33;
  my_mapping: Ellipsoid_Name="WGS 84";

or just:

int my_mapping
  my_mapping: grid_mapping_name = "EPSG:32619";

This latter shorthand is very popular and is being used right now in 
URLS sent to WMS servers to specify the projection of the map that gets 
returned.   WMS servers probably supply most of the remotely accessed 
GIS data on the Net.

If we allowed EPSG codes to be used as "grid_mapping_name", then we take 
the burden of handling all the thousands of coordinate reference systems 
from CF to the EPSG database, which seems to be the bible anyway.

If you have MS Access, you can peruse the EPSG database through the 
handy forms they provide built right into the application.  It's a 
no-brainer, even if you haven't used Access (I hadn't).

http://www.epsg.org

-Rich

Jonathan Gregory wrote:

> Listening to John and Rich, it seems to me that we should
> 
> * Extend the transverse Mercator to allow a UTM zone, say how this specifies
> TM parameters, and that the two ways are mutually exclusive (specifying both
> would be a CF error).

> 
> * Add a definition of spheroid to any projection definition where it is
> relevant, with a list of permitted values. In John's original proposal, he
> gave numbers to define the ellipsoid (semimajor axis and inverse flattening).
> Rich has given names instead. Are these alternatives? Is there a definitive
> source we could refer to?
> 
> Jonathan
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://www.cgd.ucar.edu/mailman/listinfo/cf-metadata

-- 
Richard P. Signell           rsignell at usgs.gov
U.S. Geological Survey       Phone: (508) 457-2229
384 Woods Hole Road          Fax:   (508) 457-2310
Woods Hole, MA  02543-1598