INSPIRE Thematic Clusters

FoI for ProfileObservation: Point or Curve?

230 Views

Quick question: the way ProfileObservation has been defined, the FoI is currently constrained to SF_SamplingCurve. I had thought that a Profile is always vertical (there's also a non-formalized constraint that "Profile is grid with one vertical axis"), so would have expected a SF_SamplingPoint. At the same time I've been picking up ideas on non-vertical profile (i.e. providing data on non-vertical bore-holes).

My current conclusion is that it's basically a question of which constraint to I break? (or do I just assume a vertical profile with an infinitely short Curve?)

Thoughts?

:?

Kathi

Replies

    • Public

    By Ilkka RINNE

    Hi Kathi,

    I think it makes sense to have a curve geometry for the FoI of a ProfileObservation, a point alone does not describe where did the observation "happen" sufficiently: one may want to search for ProfileObservations intersecting a particular volume of the sea (say 100 - 250 m below surface), and if the FoI only describes a point at the surface, this becomes difficult.

    The idea that the FoI geometry is continuous (the line/curve of the intended observation profile) and the domain of the result grid is a discrete (the sampling along the intended observation curve) has been helpful for me.

    • Public

    By Katharina SCHLEIDT

    Hi Ilkka,

    do you by any chance have such an example available? I tend to struggle with 3d CRS!

    Also - due to the other constraints on ProfileObservation (domain axis must be vertical), the only additional information provided by the curve is the depth, which is also covered by the GridLimits/IndexAxis

    And, my current profile isn't even based on depths but on pressure (is that vertical? ;) ). Attached.

    The more I look at the specialized observations, the more I feel we must urgently revisit and rethink some of the constraints (apart from the fact that there are serious errors!)

    :)

    Kathi

    O&M ProfileObservation Pressure Depth with GeneralGridCoverage from CIS1.1

    • Public

    By Keiran MILLARD

    Hi Kathi,

    Having a curve geometry is correct for a profile; I can't think of any truly vertical profile in the real world.  Don't confuse vertical axis with the state of being vertical.  The vertical axis can be depth or elevation (in m) or an equivalent such as pressure;  these are the two most commonly used for profiles.  Pressure is also used in the atmospheric community for profiles above the earth as well as in the oceanographic community for profiles in the ocean.

    From a representation perspective, a profle is really like a time series, except time is replaced with depth/pressure (typically) and the axes are switched.  You can have multiple phenonema observed along the profile; temperature, salinity, current speed, current direction are common.

    Keiran

    • Public

    By Katharina SCHLEIDT

    Hi Keiran,

    thanks for the info! Question - you differentiate between vertical axis and the state of being vertical. I believe that I understand the vertical axis bit (different heights or pressure readings coupled with phenomena values at one (mostly) static location represented by a coordinate pair); what do you mean with the "state of being vertical" (my mind is throwing up trash like "being an upright citizen" ;) ). As the profiles are expected to have a static geolocation, provision of a curve seems a bit absurd (becomes a sequence of line segments), the depth boundaries are provided in the result. Ilkka's example of wanting to search for observations within a specific volume of space via the FoI does make sense; think what I really want is an example of 3D encoding of the profile FoI!

    A further bit on the Profiles that bothers me is the time; the models assume one point in time, in reality this is unlikely - are the times just lumped, or are there cases where the time also gains relevance?

    Also - thanks for throwing the bit on multiple phenonema into the fray! Question here: in the atmospheric community they're basically good with providing most phenomena seperately (just because you wish to access temp and salinity together doesn't mean everybody does!); just a few integrally linked ones are to be provided as pairs (standard example is wind speed&direction, would assume the same for current). Any insights as to how the marine community views this?

    :)

    Kathi

    • Public

    By Carsten HOLLMANN

    Hi Kathi,

    a use case where the time might be relevant is, for example, when the sensor is attached to a trawl. In that case the trawl is lowered and each measurement is taken at different time stamps, different depth and at different locations. The period between the first and the last value until the trawl is brought up can be a few hours.

    In the marine community a multiple phenomenon example is the combination of conductivity, temperature and depth (CTD), where depth is given as pressure. These parameters are measured together because you can calculate the salinity of the water with them. This is a use case of a derived phenomenon and therefore it makes sense from a domain perspective to have it encoded in a structured way.

    Best,
    Carsten

    • Public

    By Katharina SCHLEIDT

    Hi Carsten,

    quick question - the trawling you describe sounds much more like a trajectory observation - am I getting confused or you?

    ;)

    Kathi

    • Public

    By Carsten HOLLMANN

    Hi Kati,

    it is a combination of trajectory and profile observation. The profile is taken at different locations along the trajectory at different time stamps. As both, location and depth are relevant for interpreting the value it was necessary to model it in this way.

    Carsten

    • Public

    By Ilkka RINNE

    Hi Carsten, an interesting case!

    I was wondering what would it mean to have the trawl observation both as a trajectory and set of profiles.

     

    Let me illustrate:

    First case: trajectory and a set of profiles (the profiles are so fast that the time period for taking each profile is irrelevant and we need to store the movement on the sensor between taking the profiles):

    Set of profiles along with a trajectory

    Second case: just a trajectory of the sensor (the profiles do not have to be literally vertical):

    Third case: just a set of profiles (the positions between the profiles irrelevant):

    If only the profile data is important, I guess this could be modelled as an observation collection containing the ProfileObservations for a specific trawl observation session.

    • Public

    By Katharina SCHLEIDT

    What I'm starting to wonder is if it even makes sense to differentiate between trajectory and profile, besides, where would we put the profiles on a trajectory?

    I think this is a further reason I'm more and more favoring moving on to the CIS 1.1 model, as a lot of these artificial differentiations get lost when one utilizes the GeneralGridCoverage

    @52°N: how hard would it be for you to implement this in the SOS?

    :?

    Kathi

    • Public

    By Katharina SCHLEIDT

    Just a short note: I've uploaded all the examples from the SeaDataCloud project to our Best Practice page at:

    https://themes.jrc.ec.europa.eu/pages/view/30357/efom-best-practices

    Includes examples of marine profile, trajectory and time series observations together with their EF