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 25/10/11 10:14, Peter Miu wrote: > Morning Martin, Hi Pete, > Sorry to hear that you were at the user conference but were not able to > attend the presentation I gave. > I've attached the presentation for information, and I welcome feedback on the > subject matter > from subscribers of this mailing list. I think I actually attended the presentation and was glad you were stating you were following the CF conventions. I mentioned the cf-satellite list several times during the session, but probably not at the end of you talk though... > The southMostLine, eastMostPixel, northMostLine, westMostPixel global > attributes are defined > to inform users who are used to using these parameters of the subarea > ordered. > This is particularly useful when users order a lot of data as it reminds them > of the contents of the data. Yes I agree that this is not essential but > adding meta-data like > this even though it may only be useful to some users adds value to the data. > Knowing the needs of your core users will help determine what type of > meta-data to specify > and your input is very useful. I see your point :) > I agree that implementing the HRV in 2 arrays is a good way to organise the > data. > This avoids a lot of cells being 'empty' which would be the case if the data > was stored in one array. > We will be revising the MSG15 NetCDF data set to include more data > stored in the native format so this will give us an opportunity to implement > the HRV channel > as well. > > Regarding your lat lon comment, Unidata provides Standard Coordinate > Transforms to > Geo-locating data onto a earth projection, see below: > > http://www.unidata.ucar.edu/software/netcdf-java/reference/StandardCoordinateTransforms.html > > This removes the need to store the lat and lon arrays in your data if you are > using Unidata > tools to visualise the data. For users who don't use these tools, it would > require them to > map these transforms to lat and lon i.e. they need to do extra programming to > visualise > the data. As I've mentioned before, usability of the data for all users is > very important > in our development. So even though the lat and lon uses space in the NetCDF > file, it is > provided for usability reasons. > > If you take a look at the presentation, we proposed the concept of tailoring > NetCDF data sets > to the user's needs. Whether the lat and lon arrays, coordination transform > or any other > method of geo-locating the data is included in the NetCDF file or not can be > addressed here. > We just need to get enough users requesting the implementation of tailored > NetCDF files (hint :o). Thanks for the hint :) Your point is perfectly valid, and it should definitely be possible to have lon/lats in the file if the user wishes, but I think it should also be possible to get only the grid-mapping definition. What I can say is that both SMHI and DMI are now using the pytroll software (pytroll.org, presented at the conference too) and we are working on it towards reading and writing netcdf files following CF, but also the discussions here. Regarding lon/lats, our approach is to use them only if there is no grid-mapping defined, as the trend seems to be (according to the cf-metadata list). Another option which is considered in Eumetsat's CDOP2 program is to have the lon/lats in a separate file. > Regarding the band discussion and taking Tom's reinforcing Email into account > (Thanks Tom ... might see you next year > in Boulder if you are there to discuss more CF conventions with you) I think > I understand what bands are now. > Creating a 3D array indexed by a band or channel with lat and lon is not a > problem. For me, I think the > channel/band should be an coordinate variable so that it can be treated like > 'level', "altitude" or "pressure level" > by the Unidata tools for visualisation. I'm also in favour of the > standard_name="channel" rather than "band" > as this is clearer to me, of course this is only my input to this discussion. > > I'm don't know who you have been talking to at EUMETSAT regarding bands but > now I know this is a user need, > I can address this in our Format Advisory Group. Thanks for drawing my > attention to this. Thanks a lot for taking this into account ! :) Best regards, Martin -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Red Hat - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOpntrAAoJEBdvyODiyJI43HAH/0QrtJSrkdCvu98/tbQJGm/0 trrFMvEXHtZIV9oNNVfDL4OvC4/F/CDxYrhzacZRyJiQ0OSZY52YQkRJ4rylHN3v OA4m3qW6nYA3Yhi6QvaRAP1Sc9N++JuYTPcypMtNT+nU5zpE9QNAsDP/XtKNAfI5 jw95t7VzDWuO/Cx5yzikd+JgIGH9RJSbtuATfW5krnszVx59CsWW+ftvtQEG+ZAc 7Y1+I3wnqQIWjnkBCrnPAHC0dbkJUWBOvcVdkTMwN/Z3sYdk6ZIZ/evFDjqh1UTE BM6sgsLD8EWk6OaFaQ2ekBWEXaMxxagbXyFOYXm65hB+0Fp8f2VBGKnV40l54+8= =y024 -----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: