NOTE: The cf-satellite mailing list is no longer active. The list archives are made available for historical reasons.
Gansham,I may be wrong, but I think what you are suggesting is pushing the boundaries of CF a bit far. I appreciate your issue, but I see a number of thorny problems that will need to be addressed. For one example, how do you specify the interpolation method? I expect that it would not be safe to assume that it would be linear, or that it would be the same in every case.
Grace and peace, Jim On 2/17/2012 9:14 PM, ghansham sangar wrote:
Hi.. Well that is a real good document. But I have a point here.According to this document for storing lat/lon information for different resolution bands we should store the lat/lon too at different resolution which I feel is a bit expensive way it blows up the product size. Some way should be worked out to store lat/lon information once only andderive lat/lon information for different resolution from there only. regards GhanshamOn Fri, Feb 17, 2012 at 7:57 PM, Jim Biard <jim.biard@xxxxxxxx <mailto:jim.biard@xxxxxxxx>> wrote:Hi.I suggest that we follow existing standards for handling this. Our primary inspiration for how to handle this should probably bethe ISO 19115-2 metadata standard. It specifies three (at least!) elements for specifying the system used for acquiring or producing the data. In short form they are project, platform, and instrument. The full names are: * /gmi:MI_Metadata/gmd:identificationInfo/gmd:MD_DataIdentification/gmd:descriptiveKeywords/gmd:MD_Keywords/gmd:keyword/gco:CharacterString with gmd:MD_KeywordTypeCode="project" (there are actually 3 different ways you can do this one!) * acquisitionInformation/MI_AcquisitionInformation/instrument/MI_Instrument/mountedOn/MI_Platform/identifier/MD_Identifier/code/CharacterString * acquisitionInformation/MI_AcquisitionInformation/instrument/MI_Instrument/citation/CI_Citation/identifier/MD_Identifier/code/CharacterString The Unidate netCDF Attribute Convention for Dataset Discovery specifies the attribute project, and this works together with THREDDS. At NOAA NCDC, where I work, we have developed a standard for the metadata we are storing in our Climate Data Records Program files. (You can see the entire standard at ftp://ftp.ncdc.noaa.gov/pub/data/sds/cdrp-guid-0042-v1.0-netcdf-metadata-guidelines-for-ioc-noaa-cdrs.pdf) As it relates to this topic, our standard specifies the use of attributes named project, platform, and sensor. They have the advantage of being applicable to a much wider variety of systems than satellites. The definitions of these attributes in the standard are (they can all be multi-valued): project Name of the scientific project(s) for which the data was created. Use as needed. If available, select a project name from the NASA GCMD Project Keywords list (see PDF reference or copy from TXT). platform Keywords for the platforms that contribute to the dataset. Select keywords from the NASA GCMD Platform Keywords list as applicable (see PDF reference or copy from TXT). sensor Keywords for the instruments that contribute to the dataset. Select keywords from the NASA GCMD Instrument Keywords list as applicable (see PDF reference or copy from TXT). Notice that in all three definitions NASA GCMD Keywords lists are referenced. These lists are a set of controlled vocabularies that contain names for many satellites that have been launched (or will be launched in the near future), the instruments that are on those satellites, and for many, many other systems. They also have a system in place for submitting new keywords. I am currently working on producing a netCDF product from NPP-JPSS (project) SUOMI-NPP (platform) VIIRS (sensor) data. I strongly recommend that we use these GCMD keyword vocabularies rather than rolling our own. You can check out all that GCMD has to offer at their web site (http://gcmd.nasa.gov/). You can download PDFs of the lists at http://gcmd.nasa.gov/Resources/valids/. Having said all that, the GCMD platform keyword for Martin's example seems to be missing! They have the platform keyword MSG, but no MSG-N, or any METEOSAT-8 or -9. I guess that means no onehas submitted them yet, or that it hasn't been published yet. This an be addressed by an interested party athttp://gcmd.nasa.gov/User/authoring.html. (You must obtain a user account to do so.) Grace and peace, Jim On 2/16/2012 10:32 AM, Martin Raspaud wrote:-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, I'm in the process of reviewing proposals for level 2 product formats (netcdf/cf) of some european cooperation. In the midst of this come the question of satellite names. It seems quite common here to interchange MSG2 with meteosat9 for example, while only the latter is the commissioning name. So there is often a mix between pre- and post-commissioning names in the documents I read. I know we haven't decided yet on any attributes, but maybe we could start making some proposals to get things clearer. So here is a first proposal for an attribute for satellite name: "satellite": The name of the satellite after commissioning, with a "-" character to separate series from number if needed. Eg: meteosat-9, goes-15 What do you think ? Best regards, Martin -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Red Hat -http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPPSGnAAoJEBdvyODiyJI46/sH/jreFU/W1bWGR2qcoJRttTiC H2l7b4qKDqrpPKSfMJOPaUje2PK+WbHJwvyvosiYk8enKoa0dL+3Z3iUReqvNfdG TJBlXI23dLRYvHBhM01jSHmtZKqfh7+J2QgZfekDBpQSeF+EDUmlhn/rh0o/8hjO crofLssihlnl4fs456LoYJJyHV7tpmdlVw3U21+mYLdlf7flq+JYkj1yn5opEPia XvMKJBkWDoIa2vpZLRQp+AfSeHQ5ZX61MbdNkENn5GJMIDBvRRczYGQVXoTEoKFJ ksu9gl0wU3VEjcqJh/zwzQhUl2eb8p0wCCm+k+WTdHoyfeUs5iXjbcVvm5Mmj7U= =3GYv -----END PGP SIGNATURE----- _______________________________________________ cf-satellite mailing list cf-satellite@xxxxxxxxxxxxxxxx <mailto:cf-satellite@xxxxxxxxxxxxxxxx> For list information or to unsubscribe, visit:http://www.unidata.ucar.edu/mailing_lists/-- Jim BiardGovernment Contractor, STG Inc. Remote Sensing and Applications Division (RSAD) National Climatic Data Center 151 Patton Ave. Asheville, NC 28801-5001 jim.biard@xxxxxxxx <mailto:jim.biard@xxxxxxxx> 828-271-4900 <tel:828-271-4900> _______________________________________________ cf-satellite mailing list cf-satellite@xxxxxxxxxxxxxxxx <mailto:cf-satellite@xxxxxxxxxxxxxxxx> For list information or to unsubscribe, visit: http://www.unidata.ucar.edu/mailing_lists/ _______________________________________________ cf-satellite mailing list cf-satellite@xxxxxxxxxxxxxxxx For list information or to unsubscribe, visit: http://www.unidata.ucar.edu/mailing_lists/
-- Jim Biard Government Contractor, STG Inc. Remote Sensing and Applications Division (RSAD) National Climatic Data Center 151 Patton Ave. Asheville, NC 28801-5001 jim.biard@xxxxxxxx 828-271-4900
cf-satellite archives: