Hi Bert,
Thanks for taking the time to fill in such detailed background on
requirements. The notion of a "grid object" seems to be growing in
popularity as the number of concepts and inter-relationships between
grids keeps piling up -- making a lot of redundant information to carry
around if it is attached to the dependent variables. 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.
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.
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).
Regarding the concerns about the CF process that I raised in earlier
emails, I am going to pursue ideas with the CF conventions committee.
It seems to me that we should begin all of our discussions of new ideas
with a clear statement of Requirements, and the opening salvos of a
discussion of the Benefits from addressing these requirements. Arguably
the link to this background material should be required in every email
message in the thread.
- Steve
===================================
Bert Jagers wrote:
> Dear Jonathan and others,
>
> Thanks for all comments and suggestions; sorry I wasn't able to
> respond the last couple of days. Let me indicate the context of my
> request.
>
> I work in the field of hydraulics, morphodynamics, water quality and
> ecology. Our modelling system is used for simulations from the scale
> of metres (flume experiments) through all length scales (detailed flow
> around groynes, dredging studies, flooding, river models from 10-100
> km, estuaries) to coastal/sea/ocean applications (storm surges,
> residual transports, tidal predictions, tsunami). We want our model
> in- and output to be stored in an international standardized file
> format such that users all over the world can easily use the system
> and process the results. NetCDF with the outlook of netCDF4/HDF5 seems
> to be the most appropriate candidate. But netCDF by itself is just a
> generic data container (slightly better, but not much better, than
> distributing our own file format together with reading routines). So,
> we need to standardise the way in which data is written to the netCDF
> file; the CF standard seems to be the only logical choice for that. As
> I see it now, I have to find solutions for the following CF-related
> challenges:
>
> 1- lat/lon and local coordinates. See below.
> 2- 1D model data, 2D/3D mosaic model data and also unstructured grid
> model data.
> 3- staggered data C-type grid with different locations for water
> levels and velocity components in grid directions.
>
> Topics 2 and 3 will be addressed in a different setting. I will
> continue with topic 1 below.
>
> As some have indicated it is possible to write non-standardized data
> in netCDF file. Well, that is probably the state that we are in right
> now. I write out 2D/3D data in a netCDF format that is similar to CF
> conventions, that was intended to be CF compliant, but unfortunately
> is not CF compliant. So far, I have said to users that it is CF
> compliant (because I was made to believe that it was indeed so) and
> have heard about no problems (only about initially lacking standard
> names). However, I do not like this situation now that I know that
> something is wrong, and I would like to really adhere to the CF
> conventions. What else is a standard good for?
>
> The applications on the largest scales (coastal/sea/ocean) are
> generally formulated in lat/lon coordinates, so, that is fine. I can
> imagine that ocean and atmospheric models are generally posed in
> generic lat/lon coordinates and that is, thus, logical for climate and
> forecast standard associated with such models to assume lat/lon
> coordinates to be known (for reasons of scale, positioning or nesting
> of models). However, many of the more local models for which the
> curvature of the earth is not relevant are based on local coordinates;
> this holds definitely for most of our river models. Even though the
> exact transformation to lat/lon coordinates may not be known, the
> model runs just fine; however, in such cases we cannot store the data
> in a CF compliant way because the lat/lon coordinates are unkown. I
> recognize and thus accept that lat/lon is the preferred way to store
> coordinate information and we, therefore, need to adjust our pre- and
> postprocessing software to deal with such cases. Luckily, the
> introduction of GIS has made coordinate transformations easier once
> you know the exact characteristics of the local coordinate system.
> However, although GIS is spreading, many non-GIS-based local data
> supply and processing tools often do not include coordinate
> transformation facilities and, therefore, they require the coordinates
> to be given also in the local coordinate system. The auxiliary
> coordinates option and grid_mapping feature offers the functionality
> to support one such local system, but due to the growing demand on
> water the number of projects at international boundaries is
> increasing. In such cases, there is not one local coordinate but more
> (in most cases two). Although in such cases the model may be
> formulated in lat/lon coordinates, the data supply should use the
> local coordinate systems. Since this request is related to the local
> coordinate systems of the countries in the considered model area, I
> think that is highly unlikely that after the data has been produced
> the number of coordinates is to be extended (question by Steve).
> However, as Jonathan indicates in the mail below one could always
> extend such files. It would, however, be possible for a large model to
> touch on three countries and thus require three coordinate systems,
> but such models would do so from the start.
>
> Instead of creating one output file with the grid specified in
> multiple coordinate systems, one could of course generate multiple
> copies of the output file with one auxiliary coordinate system each,
> but I do not like this approach. I am not against grids in different
> files as Steve proposed in the (CF provisional standards thread) but I
> my experience with such implementations from postprocessing is not so
> good (either no reference to other files, or external files missing or
> located in different directories). Steve's idea is more in line with
> John Caron's concept of a grid object with the difference that John
> keeps all coordinate systems in one file. I like the grid object
> concept because is close to the object oriented concepts in model
> coupling: OpenMI, a european standard on model coupling, uses element
> sets on which data sets are defined, the ESMF framework is also
> working in this grid object direction. By the way, I have modified
> John's example on
> http://cf-pcmdi.llnl.gov/trac/wiki/MultipleProjections to refer to
> Dutch and German coordinateSystems instead of Dutch and Belgium
> coordinate systems to reflect the coordinate systems defined. I have
> not yet read the Coordinate System Object Model page that John
> referred to, but I would be tempted to say that quantities are defined
> (at some staggered locations) on grids or meshes (or on no spatial
> data set at all), grids and meshes are specified in some coordinate
> system (one of which is WGS84 lat/lon), and coordinate systems can be
> mapped onto each other using something that is called grid_mapping in
> the CF convention.
>
> To reassure Steve, as indicated above I first need to get consistent
> transformation information into our pre- and postprocessing software
> otherwise I do not have the required lat/lon coordinate
> representation. So, we don't need to rush into a final solution yet.
> However, I did feel the need to raise this matter since I know that I
> will need it in the end.
>
> By the way: Unfortunately, different countries do not only use
> different local coordinate systems, but they often also use different
> vertical reference systems (couple of cm difference between
> Netherlands, Belgium and Germany). Such differences in vertical
> reference systems are harder to correct for; I do not want to store
> bed levels and surface elevations in different vertical reference
> systems.
>
> Best regards,
>
> Bert
>
> ----- Original Message ----- From: "Jonathan Gregory"
> <j.m.gregory at reading.ac.uk>
> To: <cf-metadata at cgd.ucar.edu>
> Sent: Monday, December 04, 2006 10:08 AM
> Subject: [CF-metadata] curvilinear cartesian coordinates case
>
>
>> Dear Steve and Bert
>>
>>> Can someone weigh in
>>> regarding the benefit side of this requirement? Will it be
>>> commonplace to require multiple grid mappings in some
>>> communities? In
>>> those communities are we confident that the number of alternative
>>> grid
>>> mappings will remain fixed?
>>
>> I presume that Bert has a definite need to store multiple grid mappings.
>> I don't think any of the solutions proposed requires the number to be
>> fixed
>> i.e. the file could be modified to add another one, using any of the
>> solutions.
>>
>>> As you know I believe personally that the cost of added complexity,
>>> of muddying concepts, etc. in CF is not given enough weight in our
>>> discussions. Often we have a pressing need to create new files,
>>> but a
>>> much vaguer future intention to create software to read those files,
>>
>> Bert, do you have a definite intention to read these 2D projection
>> coords
>> from the files? Is there a community of users for them?
>>
>> Cheers
>>
>> Jonathan
>> _______________________________________________
>> CF-metadata mailing list
>> CF-metadata at cgd.ucar.edu
>> http://www.cgd.ucar.edu/mailman/listinfo/cf-metadata
>>
>>
>> !DSPAM:27,4573e6ab48712053120893!
>>
>
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://www.cgd.ucar.edu/mailman/listinfo/cf-metadata
--
--
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/20061204/0c28598d/attachment-0002.html>
Received on Mon Dec 04 2006 - 16:27:15 GMT
