Discrete geometries - timeseries with a changing nominal position

[ludo-ifr]

Dear all
I want to store timeseries data of a fixed station using discrete geometries ( cf > 1.8)

I can use Example H.4 from cf convention - single time series

During the life of the station, it can have different nominal location.
How can I report the change of these nominal positions in a single NetCDF file?
Should I use Example H7 from cf convention - indexed ragged array

I would appreciate your help in designing such a file.
Thank you.

[JonathanGregory]

This question seems similar to cf-convention/cf-conventions#428 - maybe the answer will be the same?

[dblodgett-usgs]

The discrete sampling "geometry" part of the spec is about discrete geometry, not the more abstract concept of features. If you don't follow the distinction between geometry and feature, it's the difference between referencing by coordinates and referencing by identifier. https://docs.ogc.org/as/17-087r13/17-087r13.html and https://docs.opengeospatial.org/as/18-005r4/18-005r4.html are helpful to get some definitions.

This arrangement allows people to layer feature identifiers on top of the convention as fits their needs. Given this, I think the way to do it would be to have each nominal location identified as a different geometry but have a grouping variable to carry the station id.

So the variable you attach your cf_role = "timeseries_id" attribute to would correspond to each nominal location and you would have some other variable that would indicate that one station has multiple timeseries / geometries associated with it.

Note -- what I'm saying is that CF doesn't actually have support for your use case but you can layer your use case on top of CF in a way that is straight forward.

[ludo-ifr]

@JonathanGregory : yes it is exactly the same question

@dblodgett-usgs : thanks for pointing me that the specification is refering to geometry and not feature.
These are very theorical documents.
So I want to use the CF convention with feature using DSG and for that, as you say, I will have to layer my use case on top of CF.

   dimensions:
     station = 10 ;  // nominal positions
     obs = 1000 ;  // largest number of observation point - use missing_value for remaining obs

   variables:
     float humidity(station, obs) ;
       humidity:standard_name = "specific humidity" ;
       humidity:coordinates = "time lat lon alt station_name" ;
       humidity:_FillValue = -999.9f;
     double time(station, obs) ;
       time:standard_name = "time";
       time:long_name = "time of measurement" ;
       time:units = "days since 1970-01-01 00:00:00" ;
     float lon(station) ;
       lon:standard_name = "longitude";
       lon:long_name = "station longitude";
       lon:units = "degrees_east";
     float lat(station) ;
       lat:standard_name = "latitude";
       lat:long_name = "station latitude" ;
       lat:units = "degrees_north" ;
     float alt(station) ;
       alt:long_name = "vertical distance above the surface" ;
       alt:standard_name = "height" ;
       alt:units = "m";
       alt:positive = "up";
       alt:axis = "Z";
     string station_name(station) ;
       station_name:long_name = "station name" ;
       station_name:cf_role = "timeseries_id";
   attributes:
       :featureType = "timeSeries";

Ludovic

[dblodgett-usgs]

While arcane, the specifications I mentioned are probably worth at least pulling definitions from.

I would alter the semantics of how you apply the CF convention a bit from your example and add a couple variables. I think it would be valid to have duplicate timeseries_ids as you have setup in your example but I would have to revisit the spec. I would guess some implementations would break on this or only return one position for each timeseries because they've assumed that field to be unique. (note I also added a "Conventions" global attribute where you could declare your own extended convention)

   dimensions:
     id = 10 ;  // nominal positions
     obs = 1000 ;  // largest number of observation point - use missing_value for remaining obs

   variables:
     float humidity(id, obs) ;
       humidity:standard_name = "specific humidity" ;
       humidity:coordinates = "time lat lon alt station_name" ;
       humidity:_FillValue = -999.9f;
     double time(id, obs) ;
       time:standard_name = "time";
       time:long_name = "time of measurement" ;
       time:units = "days since 1970-01-01 00:00:00" ;
     float lon(id) ;
       lon:standard_name = "longitude";
       lon:long_name = "station longitude";
       lon:units = "degrees_east";
     float lat(id) ;
       lat:standard_name = "latitude";
       lat:long_name = "station latitude" ;
       lat:units = "degrees_north" ;
     float alt(id) ;
       alt:long_name = "vertical distance above the surface" ;
       alt:standard_name = "height" ;
       alt:units = "m";
       alt:positive = "up";
       alt:axis = "Z";
     string timeseries_id(id) ;
       timeseries_id:long_name = "unique timeseries position id" ;
       timeseries_id:cf_role = "timeseries_id";
     string station_id(id);
       station_id:long_name = "grouping id for stations that move"
     string station_name(id);
      station_name:long_name = "name corresponding to station_id groups"
   attributes:
       :featureType = "timeSeries";
       :Conventions = "CF-1.10 you-custom-convention"

[ludo-ifr]

Thanks for the example, but I do not clearly understand why I need to have the three following parameter

• timeseries_id
• station_id
• station_name

timeseries_id : unique timeseries position id : "timeserie_first_deployment", "timeserie_2nd_deployment"

station_id : grouping id for stations that move : ?

station_name : name corresponding to station_id groups : ?

[dblodgett-usgs]

The station in this case is the feature level grouping. So you would have:

timeseries_id : unique timeseries position id : "timeserie_first_deployment", "timeserie_2nd_deployment"

station_id : grouping id for stations that move : "id-1", "id-1"

station_name : name corresponding to station_id groups : "name-1", "name-1"

[ngalbraith]

If these are sequentially deployed stations, I think this file structure makes it more difficult to understand and access the data. If this data is essentially a single time series, with slight differences in x,y,z coordinates between deployments, the nominal position will likely be the most useful coordinates for most users.

Unless these deployments are at substantially different locations, or if they overlap in time, the answers to issue 428 cf-convention/cf-conventions#428 seem to me to point to a better way to represent this data.

[JonathanGregory]

@ludo-ifr, I have posted a possible way to do this for a DSG of several timeseries in issue 428.

[JonathanGregory]

I am closing this issue, since I believe it is covered by issue 428, which will soon be accepted. Thanks for raising it, @ludo-ifr.