NOTE: The cf-pointobsconvention mailing list is no longer active. The list archives are made available for historical reasons.
Jonathan (has anyone else noticed there are a lot of Jo(h)n's on this mail list? :->), At 3:57 PM +0100 9/25/07, Jonathan Gregory wrote:
Usually z is useful, but I don't think we should insist on providing something which is not really useful just to fill a slot which has been mandated.
I think it is your assessment that z is not really useful, yes? It is my assessment (with my data user hat on) that z is useful for 100% of the data sets -- not for every user of each data set, but for some users of every data set. Other data users have confirmed this, including some on this thread. Perhaps the framing of the question needs to be: For what percentage of the users of a data set will the z axis be useful? To do this analytically would require more words than any of us want to read, but my belief in this case is that the total value to users is significantly higher than the total cost to providers (assuming decent guidance is provided to the providers).
Also I don't think we should confuse the z of the quantity being measured with the z of the platform which is measuring it.
I don't think we are confusing those two values. Evidence to the contrary welcome.
John C suggests people may be prompted to supply info if the CF checker or some other such device points out it is missing. That may be more effective than laying down laws, which people may ignore. (Another argument is that an effective convention such as CF should contain things which people will agree to do - albeit a bit reluctantly - as they see the value of it, but should be careful not to prescribe excessive burdens that they will ignore as they don't see the use of them.) So if a rule can be given (in terms of something that a file-checker can apply) for when a z coordinate would usefully be present, this can be made a recommendation, and the CF checker can issue a warning if the z coord is missing. It gives warnings for unsatisfied recommendations (when that can be detected) and errors for unsatisfied requirements.
A warning is an interesting middle ground. I'm still rooting for an error, but a warning is better than nothing.
John -- ---------- John Graybeal <mailto:graybeal@xxxxxxxxx> -- 831-775-1956 Monterey Bay Aquarium Research InstituteMarine Metadata Initiative: http://marinemetadata.org || Shore Side Data System: http://www.mbari.org/ssds
cf-pointobsconvention archives: