Commit cd210cb9 authored by Håvard Futsæter's avatar Håvard Futsæter
Browse files

Rough finished notes on meeting in oslo 27.may.

parent b2948247
......@@ -60,11 +60,175 @@ Color coded categories of messages in the presentation(e.g forest fire). Also co
Separate message format for risks(not alerts yet).
###### FMI
Separate distribution for commercial and open data service?
Currently handling next day and day 1 - 5 differently. This will change. Each warning will be start to finish, independent of day.
Autogenerates texts for all CAP messages. Meteorologist defines time period, probability, area and relevant forecast parameter. No manual overrride.
Separate product for writing text to be read on the radio. Autogenerated, but with possibility for editing.
Storing results as WOML(GML based in-house format). Store in PostGres in future?
Produce multiple output formats from WOML. CAP, CAP 1.2, GeoServer WFS from PostGres ( mobile apps use that interface).
Interactive map presentation of alerts.
Fat atom feed that includes all CAP messages in the feed.
Push alerts in SOAP to meteoalarm at the moment.
Also collaborates with hydrology institute in Finland. FMI publish the warnings for them.
##### Differences between institutes
###### alert
One alert message, specifying CAP OASIS standard with xml namespace.
###### identifier
Unique string, in time and space, for an alert message. A message is the same across different representation formats, if the contents of the core elements is the same.
Must not be used to convey any information, except the identity of the message.
Format: Does not matter to FMI, MET and SMHI.
###### sender
Format: WMO Organization ID (OID).
###### sent
The time the message was produced.
###### status
Standard CAP 1.2.
Recommendation: Always have a valid "Test" message.
###### msgType
Standard CAP 1.2
UPDATE and CANCEL events by the rules of Google Public Alerts CAP-elements-Definitions.pdf
We ignore "Ack" and "Error" messages types.
###### source
Ignore this.
###### scope
Always Public
###### restriction
Ignore.
###### code
Identifies the message as following MetCoOP CAP Standard, versioned.
Format: Link to the versioned specification document.
###### note
Ignore.
###### references
Standard CAP 1.2
Clarification: UPDATE msgType must refer to all previous messages that it updates.
###### incidents
Optional, according to Standard CAP 1.2.
Future potential: Could be used for common incident registry. In that case, the identifier should be a resolvable URI.
For now, if used, it will be specific to the sender issuing the message.
###### info
Only a single info container pr. language. So, if multiple info containers, its exact same information translated into multiple languages.
###### language
Standard CAP 1.2
###### category
Standard CAP 1.2
###### event
Future controlled vocabulary in english, issued by OASIS/WMO: https://docs.google.com/spreadsheets/d/1n5hvh7S9jCqyhmr6acP0FBHq4a9O2MBlxg39J6_eUoQ/edit#gid=40743640
We will follow that vocabulary. Until then, each institute uses what its has today.
###### responseType
Standard CAP 1.2
Note: Use "AllClear" for cancelling with UPDATE msgTYpe.
###### urgency
Standard CAP 1.2
Different usage of the terms between countries may cause confusion, but a solution requires harmonizing how forecasting is done in each nation.
We will not use "Unknown"
###### severity
Different usage of the terms between countries may cause confusion, but a solution requires harmonizing how forecasting is done in each nation.
We will not use "Minor" to publish "No Warnings" messages.
We will not use "Unknown"
###### certainty
Standard CAP 1.2
Different usage of the terms between countries may cause confusion, but a solution requires harmonizing how forecasting is done in each nation.
We will not use "Unknown"
###### audience
Ignore
###### eventCode
###### effective
Not used
###### onset
When the alert starts.
Always include this. Often, it will be the same as sent.
###### expires
Its says something about the end time of the validity of this message.
The alert is valid until expired or cancelled.
Its NOT denoting the time when the weather is getting better.
We should always have a meaningful expires value.
###### senderName
We use it. Official names in local language and english etc.
###### headline
Short summary of the entire message(140 characters). Some clients might ONLY display this value.
###### decription
Mandatory
Standard CAP 1.2
###### instruction
Optional.
###### web
Mandatory.
Link to more human readable information about this alert.
#### Next steps
Finish going through the standard. Area and parameters are important subjects.
Discuss the feed and filtering services.
Engage forecast divisions for coming to an agreement on forecasting specific content of the alert.
### Next meeting
- 27th May in Oslo (full day meeting)
Meet at SMHI 2.september 2019 (full day meeting).
## Tasks
## Topics to discuss at nexxt meeting
- Each institute checks internally with the work so far, and reports back to the group.
- Check if its possible to collaborate on library for consuming and/or producing CAP. Check languages, existing libraries, resources available in the near future.
- Implemenetation roadmap.
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment