+1 for what Tom says!
This issue is becoming greater with higher resolution models where the geolocation ambiguity becomes more significant.
Jon
-----Original Message-----
From: cf-metadata-bounces at cgd.ucar.edu [mailto:cf-metadata-bounces at cgd.ucar.edu] On Behalf Of Tom Kunicki
Sent: 12 July 2011 08:20
To: John Caron
Cc: cf-metadata at cgd.ucar.edu
Subject: Re: [CF-metadata] the need to store lat/lon coordinates in a CF metadata compliant netCDF file
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-conventio
>>>> ns.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-conventio
>>>> ns.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
>>>
>>>
>>
>
> _______________________________________________
> 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
Received on Tue Jul 12 2011 - 07:46:33 BST
