Changes between Version 2 and Version 3 of PointObservationConventions


Ignore:
Timestamp:
02/11/09 13:40:31 (11 years ago)
Author:
caron
Comment:

minor edits and clarifications

Legend:

Unmodified
Added
Removed
Modified
  • PointObservationConventions

    v2 v3  
    2828The following subsections detail each point feature types and show examples of the possible representations of each.
    2929
     30Some assumption are common to all representations:
     31 
     32    * index numbering is always 0 based.
     33
    3034== 5.8.1 Point Data ==
    3135
    32 To represent data at scattered, unconnected points, both data and coordinates use the same, single dimension. The coordinates attribute is used on the data variables to unambiguously identify the time, lat, lon and height auxilary coordinate variables.
    33 
     36To represent data at scattered, unconnected points, both data and coordinates use the same, single dimension. The 'coordinates' attribute is used on the data variables to unambiguously identify the time, lat, lon and height auxiliary coordinate variables.
    3437
    3538{{{
     
    6467}}}
    6568
    66 
    6769In this example, the humidity(i) and temp(i) data are associated with the coordinate values time(i), lat(i), lon(i), and optionally alt(i). The obs dimension may use the unlimited dimension or not. If the time coordinate is ordered, the obs dimension may be named time (making time a coordinate variable rather than an auxiliary variable).
    6870
    6971== 5.8.2 Time series of Station Data ==
    7072
    71 Point data may be taken at a set of named locations called stations. The set of observations at a particular station, if ordered by time, is a time series, and the file contains a collection of time series of station data.
     73Point data may be taken at a set of named locations called stations. The set of observations at a particular station, if ordered by time, is a time series, and the file contains a collection of time series data at named locations called stations.
    7274
    7375=== 5.8.2.1 Multidimensional representation ===
    7476
    7577When the number of observations at each station is the same, one can use the multidimensional representation.
    76 
    7778
    7879{{{
     
    116117}}}
    117118
    118 
    119 The humidity(s,i) and temp(s,i) data are associated with the coordinate values time(s,i), lat(s), lon(s), and optionally vertical(s). The station dimension may be the unlimited dimension or not. All variables that have station as their outer dimension are considered to be station information. There must be a station variable (of any type) with standard_name attribute "station_id", whose values uniquely identify the station.
     119The humidity(s,i) and temp(s,i) data are associated with the coordinate values time(s,i), lat(s), lon(s), and optionally vertical(s). The station dimension may be the unlimited dimension or not. All variables that have station as their outer dimension are considered to be station information. There must be a station variable (of any type) with standard_name attribute "'''station_id'''", whose values uniquely identify the station.
    120120
    121121The time coordinate may use a missing value, which indicates that data is missing for that station and obs index. This allows one to have a variable number of observations at different stations, at the cost of some wasted space. The data variables may also use missing data values, to indicate that just that data variable is missing.
     
    125125=== 5.8.2.2 Ragged array (contiguous) representation ===
    126126
    127 When the number of observations at each station vary, one can use the ragged array representation. If you are able to store all the observations for one station contiguously, then add a field specifying the number of observations for each station.
    128 
     127When the number of observations at each station vary, one can use the 'contiguous ragged array' representation if you are able to completely control the order in which the observations are written. Add a '''rowSize''' station variable specifying the number of observations for each station. The observations for each station are stored sequentially, first for the station with index = 0, then the station with index = 1, etc.
    129128
    130129{{{
     
    169168}}}
    170169
    171 
    172170Then for each station with index stn, its observations go from
    173171
    174 
    175 {{{
    176   rowStart(stn) to rowStart(stn+1)-1
     172{{{
     173  rowStart(stn) to rowStart(stn) + nobs(stn) - 1
    177174
    178175where
     
    183180}}}
    184181
    185 The rowSize variable contains the number of observations for each station, and is identified by having a standard_name of "ragged_rowSize". It must have the station dimension as its single dimension.
    186 
    187 All variables that have station as their outer dimension are considered to be station information. There must be a station variable (of any type) with standard_name attribute "station_id", whose values uniquely identify the station.
     182The rowSize variable contains the number of observations for each station, and is identified by having a standard_name of "'''ragged_rowSize'''". It must have the station dimension as its single dimension.
     183
     184All variables that have station as their outer dimension are considered to be station information. There must be a station variable (of any type) with standard_name attribute "'''station_id'''", whose values uniquely identify the station.
    188185
    189186=== 5.8.2.3 Ragged array (non-contiguous) representation ===
    190187
    191 When the number of observations at each station vary, and the observations cannot be written in order, one can use the non-contiguous ragged array representation. Add a parentIndex field specifying the station index that the observation belongs to:
    192 
     188When the number of observations at each station vary, and the observations cannot be written in order, one can use the 'non-contiguous ragged array' representation. Add a '''parentIndex''' observation variable specifying the station index that the observation belongs to:
    193189
    194190{{{
     
    233229}}}
    234230
    235 
    236 The humidity(i) and temp(i) data are associated with the coordinate values time(i), lat(s), lon(s), and optionally alt(s), where s = stationIndex(i). The stationIndex variable is identified by having a standard_name of "ragged_parentIndex". It must have the obs dimension as its single dimension.
     231The humidity(i) and temp(i) data are associated with the coordinate values time(i), lat(s), lon(s), and optionally alt(s), where s = stationIndex(i). The stationIndex variable is identified by having a standard_name of "'''ragged_parentIndex'''". It must have the obs dimension as its single dimension.
    237232
    238233All variables that have station as their only dimension are considered to be information about that station. The obs dimension may use the unlimited dimension or not.
    239234
    240 All variables that have station as their outer dimension are considered to be station information. There must be a station variable (of any type) with standard_name attribute "station_id", whose values uniquely identify the station.
     235All variables that have station as their outer dimension are considered to be station information. There must be a station variable (of any type) with standard_name attribute "'''station_id'''", whose values uniquely identify the station.
    241236
    242237=== 5.8.2.4 Single station ===
    243238
    244239When there is only a single station in the file, one can can use any of the above representations, with number of stations = 1. One can also use scalar coordinates:
    245 
    246240
    247241{{{
     
    280274=== 5.8.2.5 Flattened representation ===
    281275
    282 When factoring out the station information is not needed, one may use a flattened representation, in which the station information is repeated for each observation. A station_id variable is required to associate the observations into a time series.
    283 
     276When factoring out the station information is not needed, one may use a 'flattened representation', in which the station information is repeated for each observation. A station_id variable is required to associate the observations into a time series.
    284277
    285278{{{
     
    319312
    320313
    321 The humidity(i) and temp(i) data are associated with the coordinate values time(i), lat(i), lon(i), and optionally alt(i). There must be a variable (of any type) with the observation dimension as its outer dimension, with a standard_name attribute "station_id", whose values uniquely identify the station.
    322 
    323 In some observational networks, station location may change. However, for station feature types this should be infrequent and not overly consequential. In principle, a new station identifier should be assigned. In practice, occasional and small adjustments to station location may not matter for typical processing of data, and generic clients may not detect these changes, eg they may assume that the first loccation encountered is valid for all other observations at the same station. Specialized clients, of course, may be more careful in examining station location data, and nothing prevents data providers from using a factored representation as above, and also putting location information into the observation record, as in the flattened representation here.
     314The humidity(i) and temp(i) data are associated with the coordinate values time(i), lat(i), lon(i), and optionally alt(i). There must be a variable (of any type) with the observation dimension as its outer dimension, with a standard_name attribute "'''station_id'''", whose values uniquely identify the station. All observations with the same station_id are assumed to belong to that station.
     315
     316In some observational networks, station location may change. However, for station feature types this should be infrequent and not overly consequential. In principle, a new station identifier should be assigned. In practice, occasional and small adjustments to station location may not matter for typical processing of data, and generic clients may not detect these changes, eg they may assume that the first location encountered is valid for all other observations at the same station. Specialized clients, of course, may be more careful in examining station location data, and nothing prevents data providers from using a factored representation as in 5.8.2.1, 5.8.2.2, and 5.8.2.3, and also putting location information into the observation record, as in the flattened representation in 5.8.2.5.
    324317
    325318== 5.8.3 Trajectory Data ==