All,
Several controversial points have been raised already in this
discussion. It seems clear that there are multiple (valid)
perspectives. My sense is that the question we need to answer is
"_Under what circumstances_ are lat/long coordinates mandatory?", rather
than a simple "yes" or "no". There are also detail-oriented issues at
the editorial level, because the current spec contains contradictory
directives.
Does someone want to volunteer to moderate this discussion and get it to
the point where it is ready to become a trac ticket.
- Steve
On 7/12/2011 12:20 AM, Tom Kunicki wrote:
An observation...
It seems implied that in CF lat/long coordinate values on their own are viewed
as authoritative. I would argue against this as these coordinate values *need*
to be qualified with their own grid_mappings to define the geodetic datum. I
am more confident dealing with coordinate values supplied with projected
coordinate systems as these values are often better geo-referenced than
lat/long coordinate values. Given the lack of a *requirement* to specify a
datum when defining lat/long coordinate values I always treat lat/long
coordinate values in CF files with caution. Forcing the user to output
lat/long values further perpetuates the idea that these values are
authoritative when in fact they would be redundant and unreliable if not
geo-referenced themselves...
Tom Kunicki
Center for Integrated Data Analytics
U.S. Geological Survey
8505 Research Way
Middleton, WI 53562
On Jul 11, 2011, at 4:12 PM, John Caron wrote:
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
_______________________________________________
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
