+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-boun...@cgd.ucar.edu [mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Tom Kunicki Sent: 12 July 2011 08:20 To: John Caron Cc: cf-metadata@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@cgd.ucar.edu >>>>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata >>>> _______________________________________________ >>>> CF-metadata mailing list >>>> CF-metadata@cgd.ucar.edu >>>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata >>> >>> >> > > _______________________________________________ > CF-metadata mailing list > CF-metadata@cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata _______________________________________________ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata _______________________________________________ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
