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!
>
Received on Mon Dec 04 2006 - 13:05:58 GMT
