I've been looking at ice/snow land/sea area types too.
I have a microwave algorithm that together with a DEM separates the world into
four mutually exclusive categories:
- land with ice or snow
- land without ice or snow
- lake/sea with ice or snow
- lake/sea without ice or snow
I'm
It’s outside of my area so I don’t have an alternative to offer, but it is bad
practice to use the names of Greek letters in standard names. Though I’m sure
the meaning in context is clear to members of the community, these letters have
different meanings in different contexts.
-- Evan
On
Sounds Good.
_Unsigned should also show up in table A.1
-- Evan
On 9/26/17, 1:39 PM, "Charlie Zender" wrote:
If there is strong opposition to replacing the valid_* method in
CF <= 1.7 with the _Unsigned method in CF 1.8 then please speak-up.
People seem to prefer
I think the _Unsigned attribute would have been a grand idea before.
But if we’re now allowing explicit unsigned types, what purpose does it serve?
Do I use the _Unsigned = “true” attribute on every ubyte, ushort, and uint
variable? They’re already clearly unsigned according to the type
Hi all,
volume_fraction_of_ozone_in_air as suggested below is perfect for AIRS. Could
we add to the proposal analogous names for CO and CH4?
volume_fraction_of_carbon_monoxide_in_air (canonical units:1)
' "Volume fraction" is used in the construction volume_fraction_of_X_in_Y,
where X
cgd.ucar.edu>
Subject: Re: [CF-metadata] Overlapping vertical bounds
What makes you think overlapping bounds are illegal?
On 3/2/17 7:20 PM, Manning, Evan M (398B) wrote:
I have some quantities which are defined on trapezoids in the vertical
direction.
For example the top trap
I have some quantities which are defined on trapezoids in the vertical
direction.
For example the top trap might be full weight from the top of the atmosphere
(TOA) to 50 hPa, then we ramp linearly between the first and second traps
between 50 & 75 hPa, then trap 2 is full weight 75-100 hPa,
It's probably overkill but for Suomi NPP CrIS and ATMS we are planning to
provide
timestamps for each obs in both TAI and UTC.
TAI is the true time dimension, but UTC gives users a correct UTC if that's
what they want and should minimize the temptation for them to do TAI to UTC
conversions
I'm defining a data set, and I have a question about reusing standard_names in
a file.
For example this a swath, so there a lat/lon/time for each observed spot.
There is also a subsatellite lat/lon and mid-scan time. And in some cases I
have separate lat/lon by MW band.
So, does every lat