identify metadata types

[tomkralidis]

Provide a list of MetOcean metadata types onto which we would like to create metadata profiles/extensions atop of OGC API - Records (draft) metadata model. From here, we can create example metadata records based on each type.

Draft explanation of type from OGC API - Records: The nature or genre of the resource being described by this record.

[chris-little]

@tomkralidis OK here we go. Is this what you meant?
Observations:

• In situ:
  • Fixed Points (land/sea, aloft/submarine, sub-soil-surface)
  • • 'Vertical' profiles (aloft/submarine)
  • Track-based (aloft/submarine)
• Remote:
  • Fixed Point (rainfall radar)
  • • 'Vertical' profiles (lidar, CBR)
  • Track based (sonar, aircraft or satellite platforms)
  • • Satellites (geostationary, sun-synchronous, others)

Gridded data

• Surface
• (aloft/submarine/sub-soil-surface)
  • by vertical coordinate type

Components of all of above:
scalar/vector/tensor, (real)/integer/enumerated/boolean

Note: forecast/obs/analysis divisions meaningless.

[tomkralidis]

Thanks @chris-little can you expand on Note: forecast/obs/analysis divisions meaningless. ? Are you saying that categorizing metadata types by, say, metoc:type=observations or metoc:type=forecast doesn't help us here?

[chris-little]

@tomkralidis I'm just saying that the traditional way that the Met Ocean community divided up their data, and metadata, is no longer helpful in a data science context. A data value in the past, present or future should not have a different structure just because of the time coordinate. Satellite and radar imagery were always viewed as observations, with observational type metadata, then we invented simulated radar and satellite imagery to visualise our forecasts.
Similarly, observations may have some metadata unique to the observational process (e.g. instrument type, calibration, etc) and a forecast of that observed value will have some specific metadata (model run, model resolution, interpolation scheme, etc) but generally the benefits are greater if both types of data are structured similarly. And common metadata wherever possible.
So the answer is yes and no! Does that make sense?

[tomkralidis]

Thanks @chris-little ; so from one viewpoint we could offer up the same core metadata for "observations" and then apply specific metadata depending on its temporal (which is different than splitting up the metadata per se)?

As well, how do we categorize granularity (i.e. an observation vs. a discoverable "set" of same)?

So some initial types could be (per opengeospatial/ogcapi-environmental-data-retrieval#40 (comment)):

• ogc:metoc:observations (or ogc:metoc:observation-set) # for collection level 'discovery'
• ogc:metoc:observation

Thoughts?

[chris-little]

@tomkralidis You may have guessed that i didn't have any thoughts recently!

When Jeremy Tandy was developing the IWXXM metamodel for aviation meteorology, using O&M, it was decided that a forecast was an observation = measurement = estimation of a value, but in the future. This approach works for TAFs, which are not gridded.

I suppose one issue is whether the observations are homogeneous or mixed. A SYNOP report could be considered a collection of observations. All the pressures from a collection of SYNOPs are also observations.

HTH

[chris-little]

@tomkralidis I did not mention the granularity aspect. Can an API retrieve a single observation value or just an aggregation of some observations?
Depends on the server and the service and the use case. E.g. serving bulk obs to an NWP model may not need fine granulariy, but a Q/C process checking an ob for realistic values may do.

[tomkralidis]

Thanks @chris-little. Could be a combination of granularity along with a different API type (i.e. a "discovery" metadata record discovered via OARec-MetOc could have link relations to an EDR API endpoint (or OAFeat, etc.)

[ShaneMill1]

From discussion 1/21/21, we determined that a really good starting point for metadata and our data types would be to begin with BUFR Table A.

Additional Background:

Specific to what is in the data

• An implementation could point to an ontology or authoritative source for terms such as a code registry.

• BUFR Table A
  http://codes.wmo.int/_bufr4
  Provides the type of data that you are looking at such as “Forecasts”, “Radar Data” etc.

[tomkralidis]

As proposed by @chris-little, we could use BUFR 4 Table A to start:

Code figure	Meaning
0	Surface data – land
1	Surface data – sea
2	Vertical soundings (other than satellite)
3	Vertical soundings (satellite)
4	Single level upper-air data (other than satellite)
5	Single level upper-air data (satellite)
6	Radar data
7	Synoptic features
8	Physical/chemical constituents
9	Dispersal and transport
10	Radiological data
11	BUFR tables, complete replacement or update
12	Surface data (satellite)
13	Forecasts
14	Warnings
15–19	Reserved
20	Status information
21	Radiances (satellite measured)
22	Radar (satellite) but not altimeter and scatterometer
23	Lidar (satellite)
24	Scatterometry (satellite)
25	Altimetry (satellite)
26	Spectrometry (satellite)
27	Gravity measurement (satellite)
28	Precision orbit (satellite)
29	Space environment (satellite)
30	Calibration datasets (satellite)
31	Oceanographic data
32–100	Reserved
101	Image data (satellite)
102–239	Reserved
240–254	For experimental use
255	Other category

Depending on our analysis/assessment, we could ask WMO ET-Data/TDCF about publishing BUFR Table A to codes.wmo.int. Or we would have our own vocabulary in our profile which would refer back to the manuals accordingly.

[tomkralidis]

Update: posted inquiry to WMO TT-CCT. fwiw we also have the tables right here on GitHub:

• working version
• latest stable version (v35)

[tomkralidis]

fwiw, another possibility from the WMO Core Metadata Profile codelists: https://github.com/wmo-im/wcmp-codelists/blob/main/codelists/WMO_CategoryCode.csv

[tomkralidis]

Another option from the WMO WIGOS Metadata Standard: http://codes.wmo.int/wmdr/_ApplicationArea