John-
John Caron wrote:
We cant change CF Conventions unilaterally, so if anyone thinks its
important that the CF conventions accept degrees_west, they should
propose that to the committtee. CF was started mostly by the global
climate modeling community, so they apparently prefer degrees_east.
I think this should be proposed to CF. Application developers will have
to account for these units, just as they do for all the other rules
(e.g. positive down for depth when unit is meters, etc).
All our projection implementations use degrees_east, not sure why other
than thats how the reference books like Snyder present them. So when we
recognize degrees_west, we have to multiply by -1 whenever we use
projections.
Since lat/lon is the output of the projection (except for the anomalous
lat/lon projection), it shouldn't matter. In VisAD we take the
convention that lat/lon transforms are in degrees_east unless otherwise
specified. I think the same could be made for the Unidata/netCDF-Java
projection code.
Im not sure what NCEP uses in its GRIB file output, but if it uses
degrees_west we are converting to degrees_east.
They always use degrees east in the 0-360 range.
Im not sure if visualization software like the IDV wants to see
degrees_west or wants them converted to degrees_east.
As long as the units are supplied, IDV will do the appropriate
conversion on the fly when necessary. That's the power of the VisAD
data model where units can be included with values (a Real). The
default unit for longitude (RealType.Longitude) is degrees_east.
As an aside, USGS uses arc-seconds for latitude/longitude in their ASCII
DEM format (still with east positive). Maintaining the original
units/values when converting to a netCDF form is important.
Don
*************************************************************
Don Murray UCAR Unidata Program
dmurray@xxxxxxxxxxxxxxxx P.O. Box 3000
(303) 497-8628 Boulder, CO 80307
http://www.unidata.ucar.edu/staff/donm
*************************************************************
