Bert Jagers wrote:
> Hi Steve,
>
>> From: Steve Hankin
>> To: Bert Jagers
>> Cc: cf-metadata at cgd.ucar.edu
>> Sent: Tuesday, December 05, 2006 12:27 AM
>> Subject: Re: [CF-metadata] curvilinear cartesian coordinates case
>
> The above message contained the following:
>
>> When we look at files that mix variables in XY with variables in XYZ
>> we'll see some redundancy in the grid objects (or else complexity), so
>> we may see the weight of the arguments shift back slightly.
>
> Can you give an example? Are you referring to generic XYZ datasets
> without independent horizontal and vertical dimensions or also XY
> variables like water levels and XYZ variables like 3D velocity fields?
Hi Bert, (& John),
On this first detail I hesitate even to take up time -- a point that
"might shift the weight of the argument slightly". It is worthy only of
a footnote, so I stuck it in as a PS at the end below.
>
>> To my eye John Caron's suggestion is the most elegant and natural of
>> the three proposed. But as part of the cost/benefit discussion one
>> needs to consider that as-is it is a departure from the CF 1.0
>> specification -- the "grid_mapping" attribute has changed its meaning
>> and is no longer attached to the dependent variables. Is this a big
>> cost?
>> There's little cost if no files have actually been created that use the
>> current grid_mapping.
>
> I think that shifting grid_mapping away from the dependent variables
> is a good step. How to deal with legacy files is indeed an issue.
>
>> However, John, isn't much of the apparent difference is just in the
>> changing interpretation of names?
>>
>> CF 1.0 John's proposed
>> grid_mapping ==> coordinateSystems
>> grid_mapping_name ==> grid_mapping
>>
>> Doesn't John's proposal using the current CF 1.0 attribute names become:
>>
>> int Dutch_CoordSystem;
>> Dutch_CoordSystem:coordinates = "dutch_x dutch_y";
>> Dutch_CoordSystem:grid_mapping_name = "EPSG19914";
>> int German_CoordSystem;
>> German_CoordSystem:coordinates = "german_x german_y";
>> Dutch_CoordSystem:grid_mapping_name = "EPSG16362";
>> float velocity(time,layer,m,n);
>> velocity:grid_mapping = "Dutch_CoordSystem German_CoordSystem" ;
>> velocity:coordinates="lat lon"; // can also list 1D coordinate
>> variables
>> float dutch_x(m,n);
>> float dutch_y(m,n);
>> float german_x(m,n);
>> float german_y(m,n);
>>
>> which is a relatively small extension of CF1.0 (and still elegant).
>
> I think there are two fundamental differences here:
I'd like to open another outlook for this entire discussion -- an
approach that might meet your goals _with no changes to CF at all_.
In the detailed use cases that you presented yesterday you motivated the
CF changes under discussion by pointing out that it would not be
desirable to create multiple files to contain the same data,
specifically "... one could of course generate multiple copies of the
output file with one auxiliary coordinate system each, but I do not like
this approach" What your use case has presented to us (I think) is a
case of multiple "views" of the same data: The data variables and their
coordinates in absolute lat/lon are immutable. But you also want to
support two or three community-specific outlooks, each requiring
specialized coordinate system information.
This statement of the problem practically shouts out "service oriented"
-- providing different flavors of the same data through multiple
interfaces. I think we can achieve that today with existing tools --
OPeNDAP and TDS. Standard netCDF clients can "simply" (in quotes) be
relinked to utilize the OPeNDAP service.
Below is a schematic representation. The basic (immutable) data file
has all of the data and the geo-referenced coordinates:
float velocity_x(time,layer,mylat,mylon);
velocity_x:long_name = "velocity, x-component" ;
velocity_x:units = "M/S" ;
velocity_x:standard_name = "x_sea_water_velocity"
velocity_x:coordinates="lat lon";
float lon(mylat, mylon) ;
lon:long_name = "longitude" ;
lon:units = "degrees_east" ;
float lat(mylat,mylon) ;
lat:long_name = "latitude" ;
lat:units = "degrees_north" ;
For the Dutch community using TDS and NcML you add the attribute
velocity_x:grid_mapping="EPSG19914";
and variables (using a TDS union)
int EPSG19914; // Dutch Rijksdriehoek
EPSG19914:grid_mapping_name = "oblique_stereographic"; // not valid
EPSG19914:longitude_of_projection_origin = 5.38763;
EPSG19914:latitude_of_projection_origin = 52.15617;
EPSG19914:scale_factor_at_projection_origin = 0.9999079;
EPSG19914:false_easting = 155000;
EPSG19914:false_northing = 463000;
double mylon(mylat,mylon);
mylon:long_name = "grid cell centres, x-coordinate, EPSG19914" ;
mylon:units = "M" ;
mylon:standard_name = "projection_x_coordinate" ;
double mylat(mylat,mylon);
mylon:long_name = "grid cell centres, y-coordinate, EPSG19914" ;
mylon:units = "M" ;
mylon:standard_name = "projection_y_coordinate" ;
And for the German community you similarly create a customized "view"
showing the EPSG16362 coordinates. You can arrange for these views to
show up neatly organized in a directory tree
http://my_institution_server/
Germany/
...files...nc
Netherlands/
...files...nc
Note that there are ways that a user can request local file copies, too,
through the service interface. There may be performance considerations,
however, depending upon file sizes and workloads.
- Steve
P.S. (footnote) On the initial point about redundant "grid object"
contents: I was referring to situations where variables like velocities
(XYZ), share the same horizontal coordinates as variables like
streamFunction (XY). The grid_mapping info for the horizontal has to be
repeated in both grids ... or alternatively, complexity has to be
introduced to represent parent (XY) and child (XYZ) grid objects.
>
==================
>
> 1) Now, the grid mapping refers to the coordinates. If there multiple
> grids are included in the file (e.g. in case of grids of staggered
> grid points, or multiple grid mosaics), this approach would require
> multiple grid mappings whereas John's original approach would define
> multiple coordinate systems* and one grid mapping. I agree with
> Jonathan's point of view that a grid mapping should not refer to
> coordinate variables.
>
> * In my previous mail, I distinguished: grids, coordinate systems and
> coordinate transformations. I don't like the way in which the term
> "coordinate system" is used in John's mail and on the coordinate
> system object model web page that he refers to. I think that the
> proper name should be a grid or mesh object: it refers to specific
> points of a more general coordinate system as I see it.
>
> A coordinate system (in my definition) refers to the general
> coordinate space (e.g. spherical coordinates as opposed to cylindrical
> or cartesian coordinates) and can be easily extended to include local
> coordinate spaces in use for geography such as Mercator projections.
> Although coordinate systems and coordinate transformations are
> fundamentally different from my point of view, it may be difficult to
> effectively seperate one from the other since most coordinate systems
> are defined by their coordinate transformation to/from spherical
> coordinates.
>
> 2) The usage of EPSG19914 as a grid_mapping_name suggests that it is
> an accepted grid_mapping_name. Although the European Petroleum Survey
> Group maintains a comprehensive list of coordinate systems. There is
> as yet no association with grid_mapping_names and CF.
>
> Note: If we continue the discussion on this proposal we might want to
> add it to the wiki page that Jonathan created:
> http://cf-pcmdi.llnl.gov/trac/wiki/MultipleProjections
>
> Best regards,
>
> Bert
--
--
Steve Hankin, NOAA/PMEL -- Steven.C.Hankin at noaa.gov
7600 Sand Point Way NE, Seattle, WA 98115-0070
ph. (206) 526-6080, FAX (206) 526-6744
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20061205/0b3ca57a/attachment-0002.html>
Received on Tue Dec 05 2006 - 11:07:30 GMT
