I agree with Rich, that we should basically keep using FGDC as much as
possible as we move into GIS, that EPSG is the standard reference for
the real details, and that an ellipsoid should be allowed on any of the
projections we have defined so far.
The EPSG databases are pretty big, and it may be unreasonable to expect
clients to implement all of them. I think a happy medium might be to
require either 1) the ellipsoid axis and flattening parameters or 2) a
few very commonly used EPSG codes that we explicitly list, such as
WGS84. Similarly, rather than allow any EPSG code for projections, we
could allow the EPSG codes for just the projections we explicitly define.
Rich Signell wrote:
> 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
>
>
Received on Tue Feb 15 2005 - 17:53:58 GMT
