18 | | === Suggestions of Coding Needs === |
19 | | * Google AlertHub Testing facility - Need to allow test-only use of the AlertHub for implementors of CAP feeds and during alerting exercises (talk to Steve Hakusa about this) |
20 | | * Notice of Direction facility - Need to allow posting of notice of works-in-progress for use by implementors, such as harmonizing CAP parameter values, promoting particular best practices for CAP feeds, etc. These are intended for efforts that are less formal than profiling, although some may progress to that over time |
21 | | * Symbol Sets facility - Need to have a source of well-known sets of symbols (pictographs) relevant to alerting. This might be organized simply as a thesaurus (entries related to each other by "broader", "narrower" and "alias for" relationships), with a simple network service for fast access to symbols |
| 18 | === Intended coding exercises === |
| 19 | 1. Develop a Sahana (OData-like) S3XML data structure to CRUD pictographs used in alerting. The teams will determine the optimal set of CAP elements to build in to the HTTP RESTful Request APIs. Thereafter, the CAP Editor, Mobile CAP Tool, and ITU CAP Software will use the APIs to publish a message with the pictograph |
| 20 | 1. Establish a set of parameters for exchanging measurement data; first document the norms in the Sahana wiki; then enhance each of the CAP-enabled tools to use the parameter values to change the visualization (e.g. flash flood water height to display the inundation region on a map). |
| 21 | 1. Emulate a Google Alerthub test base for experimenting with RSS/Atom feeds for a Common Operating Picture; using the Sahana-Eden’s Crisis Map with spatial and temporal filtering capabilities. |