[cf-pointobsconvention] Draft 2

[Keiran Millard]

Catching up on the discussions after a week's holiday so I may be going
over old ground

In my opinion there seems to be a merging of issues that would benefit
from a bit of separation.

Firstly is the separation between the spatial position of the
instrument/ship and the spatial position of the phenomena being
measured, particularly wrt the Z coordinate.  In some cases they may be
the same but, not all. 

The other separation is to treat Point, Profile, Section and
Trajectories as distinct feature types and not to collapse them.  I'm
taking definitions here from work of CSML (see
http://ndg.nerc.ac.uk/csml/ - particularly the user manual and
summarised below).  In this was you can be more specialised about a
given 'thing', e.g. a PointFeature doesn't require a Z attribute for
measurements, whereas a ProfileFeature, by its definition does.

PointFeature			Single point measurement.	
PointSeriesFeature		Time-series of single datum measurements
at a fixed location in space.
TrajectoryFeature			Measurement along a discrete
path in time and space.	
PointCollectionFeature		Collection of distributed single datum
measurements at a particular time
ProfileFeature			Single 'profile' of some parameter along
a vertical line in space.
ProfileSeriesFeature		Time-series of profiles on fixed
vertical levels at a fixed location
RaggedProfileSeriesFeature	Time-series of unequal-length profiles,
but on fixed vertical levels, at a fixed location
SectionFeature			Series of profiles from positions along
a trajectory in time and space.
RaggedSectionFeature		Series of profiles of unequal length
along a trajectory in time and space	

Incidentally I should add that I've been using the current ObsConvention
for storing fluvial data.  There are lots of similarities with marine
data, but the distribution of gauging stations are a bit like having a
collection met stations.  In my use case I have 'n' gauging stations
along a river network (=> different heights) measuring river flow (at
different depths), river depth, river temperature and various chemical
measurements.  

Best regards

Keiran



 

> -----Original Message-----
> From: cf-pointobsconvention-bounces at unidata.ucar.edu 
> [mailto:cf-pointobsconvention-bounces at unidata.ucar.edu] On 
> Behalf Of John Graybeal
> Sent: 18 September 2007 18:45
> To: Don Murray
> Cc: cf-pointobsconvention at unidata.ucar.edu
> Subject: Re: [cf-pointobsconvention] Draft 2
> 
> I think 'requiring a Z' and 'requiring a Z with every point' 
> are two different things.  I don't think anyone meant to 
> argue for the latter, or they'll correct me if I'm wrong.
> 
> To take an easy case first, for surface-based measurements 
> like ship point observations, specifying 'surface' in one 
> place for all Z coordinates (e.g., via an attribute) seems 
> like a reasonable approach. 
> 
> Hurricane track (great example) may be a little more complex 
> -- I don't know if the science would say that is a 'surface' 
> value, or something less concrete.  But it would be OK with 
> me to allow the attribute to take on a value representing an 
> abstraction, if that's necessary.
> 
> John
> 
> At 11:31 AM -0600 9/18/07, Don Murray wrote:
> >John Caron wrote:
> >>>John Graybeal wrote:
> >>>Re the Z axis, it would be nice to know for sure whether 
> the Z axis 
> >>>should be interpreted as 'surface'.  (Other possible 
> surfaces exist, 
> >>>and I suppose an abstract form of Z is also possible.  So 
> if we want 
> >>>determinism, we could either say "lack of characterization always 
> >>>means surface" or "Z must be described, if only to say it is
> >>>'surface'.")
> >>
> >>Yes, after thinking more about it, Im not so sure we should 
> allow data 
> >>that doesnt have a z coordinate. A standard I think should 
> be allowed 
> >>to insist on things like this.
> >
> >Then what do you do with a hurricane track that does not have an z 
> >associated with it?  Or a trajectory from ship point obs 
> that only have 
> >a latitude/longitude?  It seems like wasted space to have to 
> write out 
> >0 for z for every point if you don't have it and there are plenty of 
> >datasets out there without a Z value.
> 
> --
> ----------
> John Graybeal   <mailto:graybeal at mbari.org>  -- 831-775-1956
> Monterey Bay Aquarium Research Institute
> Marine Metadata Initiative: http://marinemetadata.org   ||  
> Shore Side Data System: http://www.mbari.org/ssds
> _______________________________________________
> cf-pointobsconvention mailing list
> cf-pointobsconvention at unidata.ucar.edu
> For list information or to unsubscribe,  visit: 
> http://www.unidata.ucar.edu/mailing_lists/ 


**********************************************************************
HR Wallingford uses Faxes and Emails for confidential and 
legally privileged business communications.  They do not of
themselves create legal commitments.  Disclosure to parties 
other than addressees requires our specific consent.  We are
not liable for unauthorised disclosures nor reliance upon them.  
If you have received this message in error please advise us 
immediately and destroy all copies of it.

HR Wallingford Limited
Howbery Park, Wallingford, Oxon, OX10 8BA

HR Wallingford Limited is a company registered in:
Companies House, Cardiff, Crownway, Maindy CF14 3UZ
Company No. 02562099 VAT No. GB 570 039 752
**********************************************************************