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
Received on Tue Feb 15 2005 - 12:20:54 GMT
