-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Only one "distance from reference surface" allowed per instrument instance #15
Comments
WMDR XSD defines this currently as
as part of a wmdr:deployment. The requirement can be met in one of two ways:
We need to agree on the way forward. |
I would go for option 1. As a rule, we should try to avoid CSV'ing in lieu of proper cardinality. |
For marine wind (and air temperature) observations made on board ships we need to know the height of the sensors both above the deck on which they are installed but also the sea surface. Essentially, we have one sensor but two different reference surfaces. |
height of the sensor above sea level is part of the 3D coordinates of the sensor/instrument. |
Sorry, I should rephrase this. It is the height above the water surface the is required. We also have observations from water bodies above sea level and so we have 3 height requirements. Height above sea level (important for pressure measurements) |
Following what @david-i-berry said above, in ship weather station metadata format only the height above the deck and the height above the water surface (ie height of the deck + height above the deck) are recorded. We don't have the height above sea level (which should then take into consideration tide coefficient?). We (OceanOPS) transmit to OSCAR/Surface the height above the water surface as the sensor height above local reference surface. |
(moved from wmo-cop/wmo-oscar#28)
Instrument instances (uniquely identified by manufacturer, model and serial number) might have more than one sensors/inlets at different heights. Such cases cannot be represented in the current Schema and UI. To be corrected in the next version of the schema and on the UI.
The text was updated successfully, but these errors were encountered: