Here's the rub: If we *don't* make z mandatory, this specification loses
a really good chance to massively improve the way people think about and
present their data, typically at little to no cost to themselves, but great
benefit to data users. (See Nan's email, with which my limited operational
experience agrees.) It also guarantees that lots of the data that is stored
according to the standard will be useless for further analysis by some users,
simply because the z information was not presented and thereby unknowable.
(Yes, this happens all the time with old data.)
If we *do* make it mandatory, if someone doesn't want to provide it, fine.
There is nothing that requires them to follow this specification. We could
even have another specification, all the same but with no z required, if
people are really bothered. But I think saying "we don't want to require the
Z because it's just too hard for someone to fill it in with 'not available'
(or 'decline to provide', for that matter)" is short sighted in multiple ways,
already described in previous emails. I understand that some providers won't
want to provide it, but that's true of various mandatory fields in any standard.
I think this field is an important one for observational data.
Yes we will have to provide a reference for the Z, sorry everyone. That will
be hard for people to grok at first but will quickly become easier, it will
mostly be a matter of providing good guidance.
In response to the email below:
a) data always has useful z information, whether or not it has a useful
b) sea state absolutely has a z coordinate, which is the surface of the sea (yes
that location changes relative to the earth geoid, the same as sea surface
temperature, and maybe the same guideline applies for that variable)
c) I don't know meteorology, so I don't know if total cloud amount is from ground
to space, or excludes ground fog; either way, if I'm using that data set and
am not a meteorologist, I would like to know which is true (don't forget we are
entering an era where data users are not experts in the field)
d) the altitude of the observing station is terribly important for many analyses,
and counts as the height of the measurement IF the measurement is in situ;
otherwise would be nice to have
e) considering half our buoy's surface "marine obs" are actually meteorology signals,
and the huge interaction between marine and meteorological science, I don't think
the distinction is significant for this exercise
f) data writers will always do it if (1) it's a part of the standard, and (2) they
are following the standard
At 9:27 AM +0100 9/25/07, Jonathan Gregory wrote:
I completely sympathise with encouraging people to provide useful metadata.
I would argue against a mandatory Z (or any) coordinate, though, as the
data really might not have a useful Z coordinate. I'm guessing, but
what about the sea state (its roughness due to waves)? That's a property of
the sea surface one might record, but it doesn't have a height, and the ship
observing it is obviously at sea level. Or the total cloud amount, say? This
also doesn't relate to a particular altitude in the atmosphere. You could
record the altitude of the station that observed it, but I would not say that
was really a coordinate of the cloudiness itself, and again it would not be
useful for marine obs. Requiring instead an "unknown" indicator or a missing
data indicator strikes me as excessive, and I'm not convinced data-writers
would always do it, or that it would be useful if they did. There are lots
of features of CF metadata which are very valuable but optional, such as
bounds, cell_methods and standard_names.
cf-pointobsconvention mailing list
For list information or to unsubscribe, visit:
John Graybeal <mailto:graybeal@xxxxxxxxx> -- 831-775-1956
Monterey Bay Aquarium Research Institute
Marine Metadata Initiative: http://marinemetadata.org || Shore Side Data