Hi,
With his permission, I'm forwarding this reply from Steve Kopp of ESRI
(who's not on this list). Steve Kopp suggests an interim solution
using a single string "Well Known Text" representation supported by
the OpenGIS Consortium:
http://geoapi.sourceforge.net/snapshot/javadoc/org/opengis/referencing/doc-files/WKT.html
--Russ
------- Forwarded Message
Date: Thu, 17 Feb 2005 12:45:16 -0800
From: Steve Kopp <skopp at esri.com>
To: "'Russ Rew'" <russ at unidata.ucar.edu>, Steve Kopp <skopp at esri.com>
cc: Nawajish Noman <nnoman at esri.com>
Subject: RE: [CF-metadata] Horizontal Data Coordinate System Definition [l ong] (fwd)
Russ,
Meant to email you last week about this same topic.
If the netCDF community is torn between FGDC and EPSG, we strongly recommend
EPSG, since it deals with coordinate systems all over the globe and is a de
facto standard that many softwares already work with.
Beyond this, I would suggest considering the OGC standard, which has a
keyword based string representation, as well as an XML representation, both
of which work with EPSG codes. The XML version of this is what's used in GML
and is sometimes simply referred to as the "GML coordinate system
specification".
We have built a tool to export GIS data to netCDF format, so you can see
where this really becomes important to us. We support dozens of projections
on hundreds of datums, and would rather not restrict the export tool to only
being able to create data that conforms to the short list in the CF
convention. So we'd like to put this information into the netCDF file.
Is the discussion amongst the netCDF community about supporting a larger
collection of coordinate systems something that you foresee coming together
and being agreed on this year, or is this a longer term discussion? As a
side note, there is a similar discussion happening for HDF5.
If this is a longer term discussion, could we write an OGC string into the
netCDF file? At least this way our software would recognize it, and others
would be able to use it if they wanted to, and even if they didn't want to
use it directly, could at least look at the string and know what the
coordinate system parameters are?
Or would the community prefer us to use the XML representation?
Thanks,
Steve
-----Original Message-----
From: Russ Rew [mailto:russ at unidata.ucar.edu]
Sent: Tuesday, February 15, 2005 12:43 PM
To: Steve Kopp
Cc: Nawajish Noman
Subject: [CF-metadata] Horizontal Data Coordinate System Definition [long]
(fwd)
Hi Steve and Nawajish,
I just wanted to forward to you a note that just appeared on a mailing
list for discussing and improving the CF conventions for netCDF data.
As you may know, many netCDF files don't have georeferencing that's
good enough for GIS use, and even the current CF conventions do not
require specification of a geodetic model, under the assumption that
latitudes and longitudes are typically sufficient. The note below
shows that the participants are starting to think about this now, so
the next version of the CF conventions may be better for use with GIS
software.
--Russ
------- Forwarded Message
Date: Tue, 15 Feb 2005 14:20:54 -0500
From: Rich Signell <rsignell at usgs.gov>
To: cf-metadata at cgd.ucar.edu
Subject: [CF-metadata] Horizontal Data Coordinate System Definition [long]
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
_______________________________________________
CF-metadata mailing list
CF-metadata at cgd.ucar.edu
http://www.cgd.ucar.edu/mailman/listinfo/cf-metadata
------- End of Forwarded Message
------- End of Forwarded Message
Received on Wed Feb 23 2005 - 14:32:17 GMT
