Weather forecasts, observations and warnings #643
Description
Ref: Previous issue #215 (2016) started to address this topic but with no outcome.
Proposal:
Establish path(s) to contain the data for weather forecasts, observations and warnings/alerts.
Example:
environment.weather.forecasts
environment.weather.observations
environment.weather.warnings
The intent of this issue is to revive the conversation around weather information and it's place within the Signal K model now there are a number of plugins looking to fill this gap.
Rationale:
There are a at least two plugins (possibly more) that provide weather information sources from different services and placing the resultant information in various paths under environment eg: environment.forecast, environment.outside, environment.observations.
The data structure under those paths are varied most likely based on the format of data returned from the weather service source (e.g. OpenWeather, NOAA, etc).
Additionally the use of the path environment.outside (description = "Environmental conditions outside of the vessel's hull","Environmental conditions outside of the vessel's hull") is often used for data coming from sensors on the vessel, and therefore it can be confusing to interchange this with observation data from a weather station at another location.
For a Signal K application to reliably dispay weather information it should not have to know the paths and format of data used by a particular plugin, so the goal here is to define a MVP (minimum viable product) schema for these plugin to align to.
@inspired-technologies and @sbender9 your input will be highly valued.
environment.weather.forecasts
Path containing a series of point forecasts taken at a specific location (e.g. weather station). These could be identifed by their location_id or a timestamp in ISO string format.
Using timestamp as a key will accommodate for multiple point forecasts at varying tie intervals intervals (minutes, hours, etc).
Example with timestamp as key/identifier:
environment: {
forecasts: {
<ISOTimeStamp>: {
outlook: string, // "sunny", "mostly fine", etc.
sunrise: timestamp,
sunset: timestamp,
temperature: {
value: number,
minimum: number,
maximum: number,
feelsLike: number,
dewPoint: number,
},
humidity: {
value: number
},
pressure: {
value: number
},
rain: {
value: number
},
wind: {
speed: number,
direction: number
},
cloudCover: {
value: number
},
visibility: {
value: number
},
position: { latitude: number, longitude: number},
description: string // location description
},
<ISOTimeStamp>: { ... },
<ISOTimeStamp>: { ... },
...
}environment.weather.observations
Path containing a series of obersvations at various locations (e.g. weather station). These could be identifed by their location_id or a timestamp in ISO string format.
Using timestamp as a key will accommodate for multiple point forecasts at varying tie intervals intervals (minutes, hours, etc).
Possible structure:
environment: {
observations: {
<location_id>: {
<ISOTimeStamp>: {
description: string,
position: { latitude: number, longitude: number},
outlook: string, // "sunny", "mostly fine", etc.
temperature: {
value: number,
minimum: number,
maximum: number,
feelsLike: number,
dewPoint: number,
},
humidity: {
value: number
},
pressure: {
value: number
},
rain: {
value: number
},
wind: {
speed: number,
direction: number
},
cloudCover: {
value: number
},
visibility: {
value: number
}
},
...
},
...
}
}environment.weather.warnings
Warnings could have their own path that contains a series of warnings related to a location or maybe it makes sense to have warnings as a collection within both the observations and forecasts path entries.
Signal K plugins ref: