[EAS] Humans

[Harold Price]

No one (at least not me) is suggesting trying to limit the NWS to 
what is available with EAS today.  What we are, or should be, talking 
about is how to map whatever they are doing or will be doing onto 
EAS, and onto the various presentation methods available to EAS.

Polygons are not the issue.  Dealing with them in parallel to 
EAS-only version of the same alert is - but is that even necessary 
for each type of alert?

Here is possible algorithm that could be adopted by the FCC for use 
with EAS, and might even fit into the existing rules.

One background assumption is that, for voluntary alerts, there is no 
need decide to carry an alert solely on the information provided in 
the FIPS location date in a CAP message.  You can, after all, 
manually make a decision on a case by case basis of which voluntary 
alert you want to carry, and which you don't.

A second is that, for voluntary alerts, there is no need to carry 
alerts that arrive on EAS channels - you could only carry alerts that 
arrive via CAP channels -IPAWS server, satellite, DTV backbone, 
etc.  We'll leave out how that might remove a backup path and all 
eggs in one basket until later.

This algorithm applies to voluntary alerts only, assumes the alert 
will be handled under Part 11 rules, and that the alert contains 
fields required by the IPAWS profile - including FIPS codes and 
optional polygons.

This is just one broad-stroke look at how to do it.  There are many others.

For CAP-received messages:

1) Receive an alert via CAP.  Ignore duplicate CAP messages.
2) If polygons are present, compare to the CAP/EAS device's 
user-supplied polygonal area(s) of interest.  If there is no 
intersection, exit.
3) If polygons are not present, filter based on FIPS.
4) Filter the message based on other criteria such as event.
5) Construct an EAS message from the CAP message.  Compare that to 
see if a duplicate message in the EAS domain has already be relayed, 
if so, don't relay this one.
5) Send the EAS message (with the CAP-derived text and audio).

For analog EAS-received messages
1) Receive an alert via legacy analog EAS.
2) Compare against received EAS messages, ignore duplicates
3) Fetch, or wait for, CAP messages, using an agreed-upon maximum delay time.
4) Check for a matching CAP message by building an EAS message from 
each pending CAP message, using ECIG IG rules.  If there is a match, 
log the analog message and then goto with CAP message processing above.
5) Otherwise, check to see if this voluntary message matches 
FIPS-based filters.
6) If you never want to send legacy-only voluntary alerts of this 
type, log and exit.
7) If yes, send.

With this method, you always play CAP messages first.  If you play 
the CAP message, you only play those that match your polygon 
filter.  You don't have to play a legacy-only voluntary message 
unless you want to.  Legacy-only messages can only select based on 
FIPS-codes, there is no way around that.  If you always trust your 
access to CAP sources and assume all messages will be issued via CAP, 
or just really hate legacy audio, then you can ignore legacy voluntary alerts.

Anyway, bare bones.  This works only with messages in the IPAWS EAS 
format CAP, meaning they contain FIPS codes.  I don't take the leap 
of each device making up its own FIPS codes from the polygon, because fuzz.

This does not solve the problem of an NWS CAP message that contains 
more than 31 FIPS codes.  You can't build your EAS message with a 
partial set of FIPS codes, because downstream stations won't be able 
to find the CAP message it came from, and you will be generating 
undetectable EAS duplicates.  The problem is mitigated in a local 
area of everyone decides to ignore voluntary NWS legacy messages, 
however.  Again, your tolerance for removing a backup alert source may vary.

This does not solve the general problem of finding the unique CAP 
message that generated an EAS message, because two CAP messages 
issued in the same minute might not be CAP duplicates, but might be 
EAS duplicates (because EAS only has only resolves to the minute, CAP 
has seconds).  Not likely to occur for civil alerts, more likely for 
weather alerts.

Just blue-skying here.

Harold

At 12:50 PM 10/3/2017, Botterell, Arthur at CalOES wrote:
>And NWS has a statutory duty to issue weather warnings in the best 
>way they can.  I don't think we can reasonable expect them to 
>compromise the hard-won precision of their alerts... or the reduced 
>public push-back they cause... just to accommodate the broadcast 
>industry's relatively elderly technology.