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: CAP discussion on Google and NWS public lists re CAP


Friends,

I hope everyone has seen the announcement this week from Google:
http://www.techreaders.com/2012/01/google-announces-a-public-alerts-platform
/ .  Have a look at their interface.  There is a nice treatment of USC.
These are exciting times for CAP. 

Please note the discussion below on Google groups.  There is also good
conversation on the NWS wiki that pertains to CAP
https://wiki.citizen.apps.gov/nws_developers/index.php/Category:Common_Alert
ing_Protocol .  We need to determine the best way to track these discussions
and provide appropriate responses.  There are some ideas here that we need
to capture for our CAP 2.0 work also.  Respond to this message with any
ideas you have as to the best way to do this.  The topic will be on the
EM-TC agenda 2/14.

Cheers,
Elysa



-----Original Message-----
From: google-cap-community@googlegroups.com
[mailto:google-cap-community@googlegroups.com] On Behalf Of Walker
Sent: Wednesday, February 01, 2012 8:42 PM
To: Google CAP Community
Subject: [g-cap-comm] Fundamental Issue


Having skimmed the latest CAP v1.2 doc, and the Alert Hub subscription
interface, a fundamental problem seems unanswered.

Specifically, how an entity (person, company, city, state, country) can
automatically (programmatically), without human intervention, answer the
fundamental question: does this alert affect me?

The problem is that even though the entire CAP concept is a spatial one,
that is to say that all the information in the the problem domain is
spatial, there is no spatial normalization, or even in fact mandatory
machine readable spacial information in the CAP v1.2 spec.

CAP v1.2  3.2.4  "area" Element and Sub-elements, specifies the only
mandatory element, is areaDesc

The text describing the affected area of the alert message (REQUIRED)

A text description of the affected area.

A text description is generally not considered machine readable.
...


There are several additional elements that are optional in 3.2.4 "area"
Element and Sub-elements, including coordinate point and radius, polygon of
coordinate points, and geocodes of seemingly any arbitrary system, FIPS
codes, postal codes etc.


This is all fine and good and understandable, however what an entity needs
to do to answer the fundamental question programmatically, does this alert
affect me, remains difficult to answer.

Now of course every entity could implement a solution to the problem,
including a normalization of spatial information from every encountered
geocode system, for example converting all zipcodes, FIPS codes, possibly
countries, states, counties, etc. to coordinate pair polygons. Then finding
the intersection of the polygon of what the entity considers the bounds of
itself or area of interest. Combined possibly with message type filtering,
this will finally answer the question, does this alert affect me.


...


It seems from cursory glance, that the Google Public Alerts homepage at
http://www.google.org/publicalerts
has to solve the problem described above (spatial normalization) in order to
present the variety of CAP system messages on a map display.

Now, in my opinion, one entity solving the spatial normalization problem
well and sharing the result, is preferable to thousands or millions of
entities having to tackle the same problem, and all of its associated
ongoing update issues.

I am not advocating removing any original information from an alert, any
entity could, if they so desire, implement any system of spatial
normalization they wish using the unaltered original spatial information.

If Google is normalizing the spatial data, can and will Google enrich and
add value to the CAPS data feed with that information?

That is for example, if an alert is originated with FIPS codes, ZIPCODES,
States and Counties as spatial information, and Google is already converting
it to coordinate pair polygons in order to display on a map based display,
can that enriched data be appended to the alert so subscribers can use it to
answer the question; does this alert affect me, without having to tackle the
600 pound problem of normalization themselves.

If this value added data can be appended, the only thorny remaining issue
would be of resolution, for example if a zipcode or a county takes 100kB of
data to describe every nook and cranny of its border polygon, what is an
acceptable level of smoothing of detail to reduce the poly count to
manageable levels. How is it indicated?


.....


The corresponding  process of filtering alerts to an entity is enabled by
normalization of spatial information.

How much bandwidth does a feed consume? Consider an unfiltered publication
of worldwide implementation of CAP, everybody gets all messages for the
entire world, which may or may not be OK, after all the bandwidth is
determined by the number of alerts worldwide and that is determined by the
granularity of the alerts themselves and the level of alert activity.

Even with no filtering, bandwidth of a subscription may never become an
issue in any real way as long as the link speed and capacity is high.

However if an entity, person, company, city, county, state, etc. only was
interested in CAPS data that satisfied the criteria, does this alert affect
me, or does this alert have a normalized polygon in the spatial domain that
intersects my polygon of spatial interest, then it would be possible for the
subscription service to filter CAPS messages to subscribers based on the
subscribers polygon of interest.

Again this is not advocating that a subscriber cannot  receive an unfiltered
worldwide feed, but if an entity desired, for example, the EOC of Anytown,
USA only wanted to receive alerts for their city, county, state, or the USA,
they could do so via specifying a polygon of interest.


Chris Walker







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