Hi Keiran:
Keiran Millard wrote:
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.
I think I was trying to cover the case where you want to factor out the ship
position, and have the sounding be reletive to it. If you dont care about
that (or it differs at each point), you could store the ship position with
each sounding observation.
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
We've been talking about comparing with CSML, perhaps we should go through
that exercise now?
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.
Interesting. This does sound like a station collection. is there a z dimension
to the sampling, or just a z coordinate at each guage station?
Best regards
Keiran
