There are really two related ideas here:
1) Not requiring lat/lon when valid projection (grid-mapping) info is
present. I think this is a good idea, and we should develop a "profile"
mechanism - so that the data provider can document that they are using
this variant. Maybe something like
: Conventions = "CF-1.6";
: CF-profile = "nolatlon";
2) Allowing lat/lon to live in another file. Clearly this is needed to
support what gridspec is doing.
IMO the use case for 1) is using netcdf as an exchange format, esp for
subsetting large datasets, eg the netcdf subset service. The user needs
to have the option of leaving the lat/lon out. The use case for 2) is
large archives of data - where you can rely on the files staying
together, and even being able to use absolute paths (BTW - did the spec
get changed to allow reletive paths?).
IMHO both are needed.
On 7/11/2011 2:14 PM, V. Balaji wrote:
I agree with a lot of points here. I think that grid_mappings can never
be comprehensive; I think as well that at some point it will be
prohibitive to include coordinate informtion in every file that needs
it: this is already redundant and potentially introduces two new 2D
fields alongside every variable in a bundle of (x,y) fields, even if
they happen to be on a shared grid but not in the same file.
There is also precedent for putting cell area and volume information
(which are not required by CF) in external files and referencing them.
There are emerging mechanisms for referring to external information,
which can surely be exploited here.
All that said, gridspec purposely decided not to break the existing
convention of requiring coordinate information in every file. Should
we have a specific convention proposal to state that coordinate
locations are allowed to be associated from external files?
David Blodgett writes:
Hey Steve, All,
I've been thinking about this a bit and am a bit conflicted, but I
would say it should probably not be required to include both. Not
completely sure we are all on the same page, so if this is off base,
I apologize for confusing the issue.
The real advantage to requiring that data be presented both in a
projected coordinate system (x(x) y(y)) and a geographic coordinate
system (lat(x,y) lon(x,y)) is that a person can plan on never needing
to perform transformations from projected to geographic coordinates.
However, this information is essentially redundant because there are
well known techniques to convert to/from projected coordinate systems
and their bas-geographic coordinate systems. This is akin to offering
the same data converted into two unit systems.
Since the CF conventions do not attempt to support ALL projections
(grid mappings), but rather a subset for which it is not prohibitive
to perform conversions, I tend to think that presenting data using
those projected coordinate systems only is OK. Yes, this puts some
responsibility on the CF compliant software developer to be able to
perform geographic projections, but there are some up sides too.
For data which is spatially massive, like high resolution satellite
imagery for example, storing the axis definition as two vectors of
projected coordinates requires orders of magnitude less space than
storing two 2D arrays of lat/lon cell locations. Additionally, for
grids of this type, it would likely be unreasonable to perform
spatial intersection calculations in anything but the native
"regular" grid space.
So, I think that a "grid_mapping" (meta-information) specifying the
parameters of the projected coordinate system should be required if
the coordinates represent projected real-world locations. But, the
lat/lon locations corresponding to that grid mapping should not be
strictly required.
While it seems convoluted, it may make some sense to get more
specific about these issues by saying something like: Non-standard
(from appendix F) grid mappings may be used but in this case the
latitude/longitude locations of the grid cells must be supplied.
Just my 2-cents. Hopefully this is helpful.
Dave Blodgett
Center for Integrated Data Analytics (CIDA)
USGS WI Water Science Center
8505 Research Way Middleton WI 53562
608-821-3899 | 608-628-5855 (cell)
http://cida.usgs.gov
On Jul 8, 2011, at 11:51 AM, Steve Hankin wrote:
Hi All,
Section 4.1 says:
(http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.5/cf-conventions.html#coordinate-types)
"Coordinate types other than latitude, longitude, vertical, and time
are allowed. To identify generic spatial coordinates we recommend
that the axis attribute be attached to these coordinates and given
one of the values X, Y or Z."
This is in contradiction to section 5.6:
(http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.5/cf-conventions.html#grid-mappings-and-projections)
"When the coordinate variables for a horizontal grid are not
longitude and latitude, it is required that the true latitude and
longitude coordinates be supplied via the coordinates attribute."
Section 5.6 was added after many years of CF usage in which
non-lat-long coordinate systems were regarded as valid CF files.
There are "climate and forecast" applications in which numerical
experiments are performed in purely theoretical coordinate systems
-- say, ocean models on cyclic coordinates over an idealized ocean
basin. (Much less common today than 20 years ago.)
This contradiction needs to be resolved. My opinion is that it is
section 5.6 that should be revised to say that "grid_mapping" is a
tool that is available **if a mapping is needed** -- rather than as
a required attribute whenever the coordinates are not conventional
lat-long.
Opinions?
- Steve
==============================================
On 7/7/2011 4:54 PM, John Caron wrote:
On 6/30/2011 1:26 PM, Randy Horne wrote:
Paragraph 5.6 Coordinate Reference Systems, Grid
Mappings, and Projections, first sentence:
When the coordinate variables for a horizontal grid are not
longitude and latitude, it is required that the true latitude and
longitude coordinates be supplied via the coordinates attribute.
Are there any exceptions to this "rule" ?
The reason for asking is based on a scenario where the coordinate
system and constituent locations for the data points associated
with the gridded data set can be determined solely based on the
grid mapping.
The reason for wanting to do this is to minimize the size of the
netCDF file, and the hardware resources required to process,
store, and distribute the file.
Hi Randy:
There has been no formal exception granted from this rule. The java
netcdf library does not require lat/lon as long as a valid grid
mapping is supplied. In that case, the lat/lon arrays are 2D, and
can be a significant size. When writing "CF compliant" netcdf files
(eg from netcdf subset service), the user is allowed to decide to
include lat/lon or not. Technically if not included, the files are
not fully CF compliant.
CF has mostly thought about how to make archival model data as
self-contained as possible, thus the insistence on lat/lon arrays.
I think there are other valid uses of netcdf-CF files, eg as an
exchange format, and that the lat/lon arrays should be optional.
There is currently no mechanism, eg a "profile" of CF to allow that.
John
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
