NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
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: