NOTE: The cf-satellite mailing list is no longer active. The list archives are made available for historical reasons.
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 and derive lat/lon information for different resolution from there only. regards Ghansham On Fri, Feb 17, 2012 at 7:57 PM, Jim Biard <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 be the 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 one has submitted them yet, or > that it hasn't been published yet. This an be addressed by an interested > party at http://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 listcf-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@noaa.gov828-271-4900 > > > _______________________________________________ > cf-satellite mailing list > cf-satellite@xxxxxxxxxxxxxxxx > For list information or to unsubscribe, visit: > http://www.unidata.ucar.edu/mailing_lists/ > >
cf-satellite archives: