Due to the current gap in continued funding from the U.S. National Science Foundation (NSF), the NSF Unidata Program Center has temporarily paused most operations. See NSF Unidata Pause in Most Operations for details.
Due to the current gap in continued funding from the U.S. National Science Foundation (NSF), the NSF Unidata Program Center has temporarily paused most operations. See NSF Unidata Pause in Most Operations for details.
NOTE: The cf-satellite mailing list is no longer active. The list archives are made available for historical reasons.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 24/10/11 19:36, Tom Whittaker wrote:
> Pete:
>
>>> - - On the cf-satellite list, we have long been discussing "band"s. Did you
>>> consider using those ?
>>>
>>> Sorry, I don't know what bands are.
>
> I just wanted to reinforce Martin's comments. The motivation behind
> having a 3rd "dimension" which is the band (or channel) is to provide
> applications that deal with spectra displays an easier time of getting
> at the band (channel) data for a single pixel. The HYDRA application
> is one such example. There are also potential for more efficiently
> representing common metadata as well. The reason to push on this is
> because there is no widely-accepted convention for this, and datasets
> are being created with a variety of ways of handling bands (from
> separate files, to separate variables, to the use of a 3rd dimension),
> and applications need to be able to easily recognize that a dimension
> is a "band" and not, for example, an "altitude" or "pressure level".
>
> The main issue is deciding whether this "dimension" should also be a
> "coordinate variable" as some have recommended. I believe the
> consensus right now is that it does not have to be, but it must have
> at least a "standard_name" to identify it uniquely as a "band"
> ("channel").
Yes, this is exactly what makes it nice: we don't care how the variable
is called as long as the standard_name is "band". In this way, the
reading of the file is not dependent on knowing the names for each
channel, but a generic reading that handles most satellite data in this
format files can be implemented.
Best regards,
Martin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Red Hat - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJOpk6WAAoJEBdvyODiyJI4fNkH/0VfIBnTAG27rTSKNql1irqm
dV+1LPJtmlcq59G4i/tf2yHU8zKvS/E4raYWWCQX2GIVnIS9+2v0/vP3tE7Xtz94
magtDp93U+3e9DP1vidDCK4WBotqDxCuw/fZcUn6d6Cgi+n1iRtSVD/mTSZnkSGH
uCtSCGTqkNObzh28cra6my2YXBkMTvOobX4fBOoSOVqKzKm1+BFEJCb7TaKXV9dx
LZ945/BAWLOwXkQ+BD39NolFNSzlZtOou+fUKXSOvzu9VRyUDvzivCkZPcXSISv1
BH7gQ8WawAOgcaPsbFKaAS0sukGcpk0N1lOHMsKyjZsCEO9J39KclFww340l2Ao=
=aQjM
-----END PGP SIGNATURE-----
begin:vcard fn:Martin Raspaud n:Raspaud;Martin org:SMHI adr;quoted-printable;quoted-printable:;;Folkborgsv=C3=A4gen 1;Norrk=C3=B6ping;;60176;Sweden email;internet:martin.raspaud@xxxxxxx tel;work:+46 (0)11 495 8261 tel;cell:+46 (0)11 495 8261 url:www.smhi.se version:2.1 end:vcard
cf-satellite archives: