[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]