High Frequency Radar (HFR) sea surface current measurements

[LorenzoCorgnati]

1. The High Frequency Radar (HFR) technology

High-frequency radars (HFRs) are shore-based instruments that remotely sense the surface ocean currents over extended coastal areas at high resolutions in space and time. They provide synoptic velocity maps reaching offshore distances of 30–200 km with a spatial resolution of 0.2–6 km depending on their emitting frequency, with a temporal resolution typically between 15 min and 1 h.
In addition to surface currents, HFRs also provide derived wave and wind measurements that show significant potential, although they have not yet been adopted widely for operational monitoring.

In the last few decades, they have become an essential worldwide component of coastal ocean observing systems thanks to their extensive near real-time spatial coverage that provides an invaluable dynamical framework to other more localized in situ observation platforms. HFR data play an essential role in addressing environmental and societal problems and applications. These include environment conservation and fishery management through an understanding of the larvae transport in the surface layer; pollutant mitigation through the reconstruction of pollutant dispersion and retention, for instance, in the case of oil spills; coastal management, for instance, through monitoring the impact of port activities on marine protected areas; maritime security, in support of Search and Rescue (SAR) operations and vessel navigation; and other emerging applications such as the monitoring of extreme events, tsunami detection, and ocean energy production.

HFR technology, founded on the principle of Bragg scattering of the electromagnetic radiation over the rough conductive sea surface (Crombie, 1955), infers the radial current component from the Doppler shift of radio waves backscattered by surface gravity waves of half their electromagnetic wavelength. HFR systems transmit electromagnetic signals in the high-frequency range 3-30 MHz, with corresponding wavelengths in the range 100-10 m.

HFRs provide continuous information in terms of 2-D surface velocity. The spatial horizontal averaging in range and azimuth depends on the radar configuration, whereas the exponentially weighted vertical averaging occurs from the surface to a depth of λ/8π, where λ is the transmitted wavelength, which corresponds to values in the range 0.4–4 m for the considered transmitting frequencies.

Since each single radar estimates current components moving along radial directions (toward or away) with respect to the antenna (radial currents), total surface velocity maps can be obtained by geometrically combining data from at least two radar sites in their overlapping coverage, provided some geometrical constraints are satisfied.

The main uncertainty source in the combination of radials into total velocities is the geometry of the radar network (i.e., reciprocal positions of the contributing sites). The geometric uncertainty is based on the incidence angles between the radial component vectors at the grid point of the total vector map, commonly referred as the geometric dilution of precision (GDOP). The more the relative angles between radials move away from orthogonality, the higher is the geometric uncertainty.

Other unavoidable error sources affecting radial data are related to electromagnetic interferences, ionosphere clutter, or other environmental noise. These errors cause variability in time and space of the available radial data coverage, thus impacting the standard deviations of the collected measurements (each measurment is an average in time and space, thus each measurement is equipped with temporal and spatial standard deviations).

2. The variables

Under the coordination of the EuroGOOS High Frequency Task Team, the European HFR Node (https://www.hfrnode.eu/) operates a service for automatically collecting HFR measurements from European and US networks, applying the QC procedures agreed by the community, converting them into the standard data model and distributing them towards the main marine data portals as Near Real Time and Delayed Mode products.

According to the standard data model, HFR data are packed in netCDF-4 files compliant with Climate and Forecast Metadata Convention CF-1.11.

The netCDF data files contain geophysical variables (coordinates and velocity variables), statistical variables (standard deviations and covariances), purely geometrical variables (GDOP), QC variables (variable names ending with "_QC") and "abstract" variables (site codes, number of antennas, SeaDataNet namespace variables). The QC variables contain flags obtained by applying the thresholding defined per each QC procedure. Each QC procedure has a dedicated QC variable. An overall QC variable is present reporting the logical sum of all the other QC variables.

The variables contained in the netCDF data files are listed below, for both radial and total velocity fields.

2.1. Variables in radial data files

TIME (days since 1950-01-01T00:00:00Z) = Time = time
BEAR (degree_true) = Bearing away from instrument =
RNGE (km) = Range away from instrument =
DEPTH (m) = Depth = depth
LATITUDE (degree_north) = Latitude = latitude
LONGITUDE (degree_east) = Longitude = longitude
XDST (km) = Eastward distance from instrument =
YDST (km) = Northward distance from instrument =
crs = Coordinate reference system =
SDN_CRUISE = Grid grouping label =
SDN_STATION = Grid label =
SDN_LOCAL_CDI_ID = SeaDataNet CDI identifier =
SDN_EDMO_CODE = European Directory of Marine Organisations code for the CDI partner =
SDN_XLINK = External resource linkages =
RDVA (m s-1) = Radial sea water velocity away from instrument = radial_sea_water_velocity_away_from_instrument
DRVA (degree_true) = Direction of radial vector away from instrument = direction_of_radial_vector_away_from_instrument
EWCT (m s-1) = Surface eastward sea water velocity = surface_eastward_sea_water_velocity
NSCT (m s-1) = Surface northward sea water velocity = surface_northward_sea_water_velocity
ESPC (m s-1) = Radial standard deviation of current velocity over the scatter patch =
ETMP (m s-1) = Radial standard deviation of current velocity over the coverage period =
HCSS (m2 s-2) = Radial variance of current velocity over coverage period =
EACC (m s-1) = Radial accuracy of current velocity over coverage period =
MAXV (m s-1) = Radial sea water velocity away from instrument maximum = radial_sea_water_velocity_away_from_instrument
MINV (m s-1) = Radial sea water velocity away from instrument minimum = radial_sea_water_velocity_away_from_instrument
ERSC = Radial sea water velocity spatial quality count =
ERTC = Radial sea water velocity temporal quality count =
SPRC = Radial sea water velocity cross spectra range cell =
TIME_QC = Time quality flag =
POSITION_QC = Position quality flag =
DEPTH_QC = Depth quality flag =
QCflag = Overall quality flag =
OWTR_QC = Over-water quality flag =
MDFL_QC = Median filter quality flag =
VART_QC = Temporal derivative quality flag =
CSPD_QC = Velocity threshold quality flag =
AVRB_QC = Average radial bearing quality flag =
RDCT_QC = Radial count quality flag =
NARX = Number of receive antennas =
NATX = Number of transmit antennas =
SLTR (degree_north) = Receive antenna latitudes = deployment_latitude
SLNR (degree_east) = Receive antenna longitudes = deployment_longitude
SLTT (degree_north) = Transmit antenna latitudes = deployment_latitude
SLNT (degree_east) = Transmit antenna longitudes = deployment_longitude
SCDR = Receive antenna codes =
SCDT = Transmit antenna codes =

2.2. Variables in total data files

TIME (days since 1950-01-01T00:00:00Z) = Time = time
LATITUDE (degree_north) = Latitude = latitude
LONGITUDE (degree_east) = Longitude = longitude
DEPTH (m) = Depth = depth
crs = Coordinate reference system =
SDN_CRUISE = Grid grouping label =
SDN_STATION = Grid label =
SDN_LOCAL_CDI_ID = SeaDataNet CDI identifier =
SDN_EDMO_CODE = European Directory of Marine Organisations code for the CDI partner =
SDN_REFERENCES = Usage metadata reference =
SDN_XLINK = External resource linkages =
EWCT (m s-1) = Surface eastward sea water velocity = surface_eastward_sea_water_velocity
NSCT (m s-1) = Surface northward sea water velocity = surface_northward_sea_water_velocity
EWCS (m s-1) = Standard deviation of surface eastward sea water velocity =
NSCS (m s-1) = Standard deviation of surface northward sea water velocity =
CCOV (m2 s-2) = Covariance of surface sea water velocity =
UACC (m s-1) = Accuracy of surface eastward sea water velocity =
VACC (m s-1) = Accuracy of surface northward sea water velocity =
GDOP = Geometrical dilution of precision =
TIME_QC = Time quality flag =
POSITION_QC = Position quality flag =
DEPTH_QC = Depth quality flag =
QCflag = Overall quality flag =
VART_QC = Temporal derivative quality flag =
GDOP_QC = GDOP threshold quality flag =
DDNS_QC = Data density threshold quality flag =
CSPD_QC = Velocity threshold quality flag =
NARX = Number of receive antennas =
NATX = Number of transmit antennas =
SLTR (degree_north) = Receive antenna latitudes = deployment_latitude
SLNR (degree_east) = Receive antenna longitudes = deployment_longitude
SLTT (degree_north) = Transmit antenna latitudes = deployment_latitude
SLNT (degree_east) = Transmit antenna longitudes = deployment_longitude
SCDR = Receive antenna codes =
SCDT = Transmit antenna codes =

2.3. Relevant vocabulary terms

According to the SeaDataNet (SDN) extension to CF, which is concerned with providing storage for standardized semantics and metadata, the HFR standard data model includes four mandatory parameter attributes for each data and coordinate variable, which are:

• sdn_parameter_urn – this is the URN for the parameter description taken from the P01 vocabulary;
• sdn_parameter_name – this is the plain language label (Entryterm) for the parameter taken from the P01 vocabulary at the time of data file creation;
• sdn_uom_urn – this is the URN for the parameter units of measure taken from the P06 vocabulary;
• sdn_uom_name - this is the plain language label (Entryterm) for the parameters’ units of measure, taken from the P06 vocabulary at the time of data file creation.

Since URNs are reported instead of URIs, these attributes are not machine-actionable. Gwen will review/create suitable P01 terms for HFR surface current data and the HFR data model will be updated for including URIs instead of URNs.

The SDN "semantics" terms included in the HFR data model are reported in the table below, for both radial and total data.

Variable	sdn_parameter_name	sdn_parameter_urn	sdn_uom_name	sdn_uom_urn
TIME	“Elapsed time (since 1950-01-01T00:00:00Z)”	“SDN:P01::ELTJLD01”	“Days”	“SDN:P06::UTAA”
BEAR	“Bearing”	“SDN:P01::BEARRFTR”	“Degrees true”	“SDN:P06::UABB”
RNGE	“Range (from fixed reference point) by unspecified GPS system”	“SDN:P01::RIFNAX01”	“Kilometres”	“SDN:P06::ULKM”
DEPTH	“Depth below surface of the water body”	“SDN:P01::ADEPZZ01”	“Metres”	“SDN:P06::ULAA”
LATITUDE	“Latitude north”	“SDN:P01::ALATZZ01”	“Degrees north”	“SDN:P06::DEGN
LONGITUDE	“Longitude east”	”SDN:P01::ALONZZ01”	“Degrees east”	“SDN:P06::DEGE”
RDVA	“Current speed (Eulerian) in the water body by directional range-gated radar”	“SDN:P01::LCSAWVRD”	“Metres per second”	“SDN:P06::UVAA”
DRVA	“Current direction (Eulerian) in the water body by directional range-gated radar”	“SDN:P01::LCDAWVRD”	“Degrees True”	“SDN:P06::UABB”
EWCT	Eastward current velocity in the water body”	“SDN:P01::LCEWZZ01”	“Metres per second”	“SDN:P06::UVAA”
NSCT	Northward current velocity in the water body”	“SDN:P01::LCNSZZ01”	“Metres per second”	“SDN:P06::UVAA”
EWCS	“Eastward current velocity standard deviation in the water body”	“SDN:P01::SDEWZZZZ”	“Metres per second”	“SDN:P06::UVAA”
NSCS	“Northward current velocity standard deviation in the water body”	“SDN:P01::SDNSZZZZ”	“Metres per second”	“SDN:P06::UVAA”
CCOV			“Square metres per second squared”	“SDN:P06::SQM2”
GDOP			“Dimensionless”	“SDN:P06::UUUU”
UACC			“Metres per second”	“SDN:P06::UVAA”
VACC			“Metres per second”	“SDN:P06::UVAA”
ESPC			“Metres per second”	“SDN:P06::UVAA”
ETMP			“Metres per second”	“SDN:P06::UVAA”
ERSC			“Dimensionless”	“SDN:P06::UUUU
ERTC			“Dimensionless”	“SDN:P06::UUUU
HCSS	“Current speed standard deviation in the water body”	“SDN:P01::SDSAZZ01”	“Metres per second”	“SDN:P06::UVAA”
EACC			“Metres per second”	“SDN:P06::UVAA”
XDST			“Kilometres”	“SDN:P06::ULKM”
YDST			“Kilometres”	“SDN:P06::ULKM”
SPRC			“Dimensionless”	“SDN:P06::UUUU
NARX			“Dimensionless”	“SDN:P06::UUUU
NATX			“Dimensionless”	“SDN:P06::UUUU
SLTR	“Latitude north”	“SDN:P01::ALATZZ01”	“Degrees north”	“SDN:P06::DEGN
SLNR	“Longitude east”	”SDN:P01::ALONZZ01”	“Degrees east”	“SDN:P06::DEGE”
SLTT	“Latitude north”	“SDN:P01::ALATZZ01”	“Degrees north”	“SDN:P06::DEGN
SLNT	“Longitude east”	”SDN:P01::ALONZZ01”	“Degrees east”	“SDN:P06::DEGE”
SCDR			“Dimensionless”	“SDN:P06::UUUU
SCDT			“Dimensionless”	“SDN:P06::UUUU

3. Variable modelling

A first attempt for modelling the HFR surface current variables towards I-ADOPT and OMS schemas was made.
The modelling was tried separately for the different types of variables: geophysical variables (coordinates and velocity variables), statistical variables (standard deviations and covariances), purely geometrical variables (GDOP), QC variables (variable names ending with "_QC") and "abstract" variables (site codes, number of antennas, SeaDataNet namespace variables).

3.1. Geophysical variables

The modelling of the geophysical variables is available at: https://docs.google.com/spreadsheets/d/1bKcszXquDe5LaP9tS44bv810khrrNNBF/edit?usp=sharing&ouid=113551181318731355489&rtpof=true&sd=true

The main open issues to be addressed are:

• definition of the Matrix
• definition of the ContextObject
• definition of the Constraint, if needed: in particular it has to be decided if the HFR transmitting frequency has to be set as a constraint to the ContextObject "surface water" for specifying that the thickness of the surface layer to which the measurements apply depends on the transmitted frequency. Another option is to avoid the Constraint and specifying the HFR transmitting frequency in the OMS Observer class.
• definition of the Ultimate and Proximate FeatureOfInterest
• definition of the ObservingProcedure: in particular, the level of detail should be defined
• definition of the Deployment: shall it be the time period in which the measuring system has been operational?
• definition of the Observer in the case of total velocity data: total velocity data are computed starting from the radial measurements of at least two HFR systems. Shalll the Observer specify all the contributing HFR sites within the HFR network set as Host?

3.2. Geometrical variables

The modelling of the geometrical variables is available at: https://docs.google.com/spreadsheets/d/1GhRaKPTQDmG3usu2X2qmQB2Cw5kFH_4A/edit?usp=sharing&ouid=113551181318731355489&rtpof=true&sd=true

The main open issues to be addressed are:

• definition of the Property
• definition of the ObjectOfInterest
• definition of the Matrix, if needed
• definition of the ContextObject, if needed
• definition of the Constraint, if needed
• definition of the Ultimate and Proximate FeatureOfInterest
• definition of the ObservingProcedure: in particular, the level of detail should be defined
• definition of the Deployment: shall it be the time period in which the measuring system has been operational?
• definition of the Observer in the case of total velocity data: total velocity data are computed starting from the radial measurements of at least two HFR systems. Shalll the Observer specify all the contributing HFR sites within the HFR network set as Host?

3.3. Statistical variables

The modelling of the statistical variables is available at: https://docs.google.com/spreadsheets/d/1jXEi2JCNw4Wn6aTruKyN4Fb0PZmDZCGY/edit?usp=sharing&ouid=113551181318731355489&rtpof=true&sd=true

The main issue to be discussed is related to the statistical nature of these variables, because I-ADOPT has no statistical concepts at present.

The main other open issues to be addressed are:

• definition of the Matrix
• definition of the ContextObject
• definition of the Constraint, if needed: in particular it has to be decided if the HFR transmitting frequency has to be set as a constraint to the ContextObject "surface water" for specifying that the thickness of the surface layer to which the measurements apply depends on the transmitted frequency. Another option is to avoid the Constraint and specifying the HFR transmitting frequency in the OMS Observer class.
• definition of the Ultimate and Proximate FeatureOfInterest
• definition of the ObservingProcedure: in particular, the level of detail should be defined
• definition of the Deployment: shall it be the time period in which the measuring system has been operational?
• definition of the Observer in the case of total velocity data: total velocity data are computed starting from the radial measurements of at least two HFR systems. Shalll the Observer specify all the contributing HFR sites within the HFR network set as Host?

[LorenzoCorgnati]

@gwemon @annefou I tried to model the geophysical variables measured by HFR systems and I summarized my main doubts in the case study description (Section 3.1). You'll find all the cells related to the doubts highlighted in yellow. Could you please have a look and give some feedback?
Anyway, as we said in Vienna, we could have a call for discussing together.

[LorenzoCorgnati]

@gwemon @annefou I tried to model the geometrical variables related to HFR measurements, namely GDOP. Here I've doubts almost on everything. Again, we should have a call to further discuss this variable.

[LorenzoCorgnati]

@gwemon @annefou I tried to model the statistical variables related to HFR measurements, namely standard deviation and variance. It's just a very first attempt because I did not study the SMTX and RDF-Q frameworks.
Anyway I guess we should discuss about these statistical parameters. I know that P01 vocabulary contain terms for standard errors for eastward, northward and radial velocities. I remember that @gwemon said that these could be broad sets that can include different types of errors. But they are defined as "The standard error of the mean (defined as the standard deviation divided by the square root of the sample size) of multiple determinations of the specified phenomenon.".
I don't know if these terms can include also "accuracy", that is another variable related to HFR data.

For these variables I did not prepare the OMS sketches, because these are not observed properties. They're evaluated properties. I need some clarification on this point (that also applies for GDOP).

[gwemon]

@LorenzoCorgnati Just responding to your last comment about the statistical parameter, if the method used to determine the uncertainty of the measurement is either unknown or best left unspecified then we do have a term for this in our S07 vocabulary: uncertainty aka measurement "error"- So we could construct a P01 for the uncertainties on your measured parameters similar to https://vocab.nerc.ac.uk/collection/P01/current/CSEREWHF/ but with "uncertainty" instead of "standard error". Alternatively we could also be more specific and use standard deviation

[gwemon]

Also @LorenzoCorgnati, regarding the best way to capture/model statistical parameters I think this is a discussion that need to happen across all the domains, however I find it really interesting the way you modelled the statistical variables using I-ADOPT here by making the statistical parameter "standard deviation" the iop:Property and the quantity measured "Eastward velocity" the iop:OoI. I had never thought about it that way but I do like it.

[LorenzoCorgnati]

@LorenzoCorgnati Just responding to your last comment about the statistical parameter, if the method used to determine the uncertainty of the measurement is either unknown or best left unspecified then we do have a term for this in our S07 vocabulary: uncertainty aka measurement "error"- So we could construct a P01 for the uncertainties on your measured parameters similar to https://vocab.nerc.ac.uk/collection/P01/current/CSEREWHF/ but with "uncertainty" instead of "standard error". Alternatively we could also be more specific and use standard deviation

@gwemon In HFR datasets we have error variables for both accuracy and standard deviation. If I got your proposition right, I like it very much: we could build a P01 term based on the S07 term "uncertainty" and keep (or refine if needed) the P01 term based on "standard deviation". If possible, we also should try to build a P01 term based on the concept of "variance". Would this be possible?

[LorenzoCorgnati]

Also @LorenzoCorgnati, regarding the best way to capture/model statistical parameters I think this is a discussion that need to happen across all the domains, however I find it really interesting the way you modelled the statistical variables using I-ADOPT here by making the statistical parameter "standard deviation" the iop:Property and the quantity measured "Eastward velocity" the iop:OoI. I had never thought about it that way but I do like it.

@gwemon As you know, I'm no expert of the field, but this description seemed to me the easiest way to describe our variable. If, after having discussed cross-domain and having studied the SMTX and RDF-Q frameworks, we find out that standard deviation, uncertainty and variance could be iop:Property, this could be a way to test.