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 John... > 2) the question of having to include calculated lat/lons has also been > discussed many times. I have advocated making these optional, but my opinion > has not prevailed (yet). The Netcdf-Java software does not require them as > long as a projection (grid_mapping) is specified. Other software may not > know how to deal with the projections, so thats the argument for including. I agree with this -- there is no need to have both. The key thing is that the application have a library-supplied way to navigate the pixels -- for current MSG and upcoming GOES-R, the projections are "fixed", so it would make sense to only define a projection for this and not supply lat/lon values for each pixel. tom -- Tom Whittaker University of Wisconsin-Madison Space Science & Engineering Center (SSEC) Cooperative Institute for Meteorological Satellite Studies (CIMSS) 1225 W. Dayton Street Madison, WI 53706 USA ph: +1 608 262 2759
cf-satellite archives: