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
>>> CF-metadata at cgd.ucar.edu
>>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>> _______________________________________________
>> CF-metadata mailing list
>> CF-metadata at cgd.ucar.edu
>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
>
--
V. Balaji Office: +1-609-452-6516
Head, Modeling Systems Group, GFDL Home: +1-212-253-6662
Princeton University Email: v.balaji at noaa.gov
Received on Mon Jul 11 2011 - 14:14:34 BST
