OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

emergency message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [OASIS Issue Tracker] (EMERGENCY-26) Eliminate multiple Infos altogether


    [ https://tools.oasis-open.org/issues/browse/EMERGENCY-26?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=37619#comment-37619 ] 

Norm Paulsen commented on EMERGENCY-26:
---------------------------------------

Actually my position is independent of the any engineering solution or practice we follow. Single info block only CAP messages would not be hard to switch too (couple days of work). Conversely, any consumer that can handle multiple info blocks would be able to handle single ones just as easy. So no firm digging on the engineering side has occured.

Although it hasn't happened yet I'm expecting there will be consumers that will want me, or some middleman, to take my CAP and transform them into single info block CAP messages. I use your philosophy on this "agencies are alway entitled to their own judgements". 

The marginal cost of individual CAP messages comes in the treatment of them by consumers, not anything we do. No artifact of implementation here as none of routing, distribution, file sizes, # of files, factored into our originator design at all. None of that registers a blip on the amount of stuff flying around our networks.

Squaring the circle between hazard footprints and political boundaries is an impact on bifurcation no doubt,  but even using hazard event polygons (t=time x), or threat polygons (t= time x through to time y) without political boundary complications can cause the bifurcation problem in large moving storms with multiple hazards.

I wlecome the chance to explore this together. A Use Case for a large moving multi hazard storm is what I believe I need to demonstrate. In the mean time, all this is just to illustrate my preference for Multiple Info blocks over single.

Notes for Art:
- We in Canada don't mix hazards into CAP messages. Each hazard gets its own chain of CAP messages, even in large moving storms. So no multiple info block messages with different hazards per block exist in our system. This was done for a ccompletely differnet reason not pertinent here.






> Eliminate multiple Infos altogether
> -----------------------------------
>
>                 Key: EMERGENCY-26
>                 URL: https://tools.oasis-open.org/issues/browse/EMERGENCY-26
>             Project: OASIS Emergency Management TC
>          Issue Type: Improvement
>          Components: CAP 
>            Reporter: Art Botterell
>
> This is a more radical version of EMERGENCY-25:  Even in the case of multi-lingual messaging the requirement (which is essentially administrative) could be met by issuing multiple CAP messages, each in a different language.  This would simplify both implementation and operation by decoupling the workflows for different languages and generating a separate CAP Alert for each.
> Since relatively few message originators are fluent in all the languages required of them by their various local operating rules, those language-specific workflows are necessarily different; coupling them in the technology can lead to avoidable delays and complications.
> (The original design was informed by preconceptions and political pressures and I take full personal responsibility for its imperfections.)



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]