[CAP] Need advice on FIPS code to Polygon conversion

[Art Botterell]

Of course starting from FIPS codes is inherently imprecise... in the  
longer term we want to move to originating our area boundaries in  
geospatial terms so we don't need to do that sort of conversion.   
However, it seems unavoidable that some systems will confuse pre- 
computed administrative boundaries with actual hazard boundaries for  
some time to come.

What's needed... and I'm sure somebody knows an efficient way to do  
this... is a tool to take full-resolution GIS polygons and simplify  
them.  (I believe this is called a "concave hull" computation.)  For  
CAP purposes I'd suggest that something like twenty vertices in the  
result might be a practical maximum.

Of course the extreme simplification is just a rectangular bounding  
box defined by the maximum and minimum latitude and longitude values  
in the source poly.  That might suffice for some purposes, given that  
using political boundaries (e.g., FIPS codes) to describe hazards is  
so imprecise to begin with.  However, it still adds quite a bit of  
"spill" to the message targeting, especially if the source polygon is  
concave on any side.  (E.g., a bounding box on California would  
include most of Nevada.)

Plus, reducing areas to their bounding boxes on an important data  
source might seduce developers of CAP clients into relying on simple  
bounds-checks instead of proper point-in-polygon and polygon- 
intersection tests, which could leave us with an awkward legacy later.

In the past I've seen this reduction process done by manually tracing  
around the source polygon.  But to do that for all the FIPS codes,  
weather zones and other pre-computed boundaries in the U.S. would be  
tedious, even if it were a one-time project, so some sort of  
computational tool would be handy.

- Art



On Sep 14, 2008, at 9/14/08 11:08 AM, Bob Bunge wrote:

> All,
>
> Recently released experimental NWS CAP 1.1 feeds:
>
> http://www.weather.gov/alerts-beta/
>
> Like the EDIS feeds, these have atom indexes.  The CAP messages are  
> much more broken out and include a number of parameters that are  
> unique to NWS like the UGC and VTEC sections.  U-S-C values are  
> assigned as well.
>
> Polygons are included for products were we issue polygons (Storm  
> Based Warnings in NWS-speak).  FIPS and UGC codes and zone numbers  
> are offered for all messages.
>
> NWS maintains shapefiles for zones and counties here:
>
> http://www.weather.gov/geodata/
>
> Through these shapefiles, it is possible to cross map and build  
> polygons.  In theory we could send the polys for all, but that would  
> really grow the size of the message, specially if we chose to send  
> high resolution points.
>
> Perhaps the first use of these new feeds is to drive outdoor  
> electronic signs at Walgreen stores:
>
> http://www.marketwatch.com/news/story/walgreens-electronic-outdoor-signs-now/story.aspx?guid=%7B954485D3-75EA-41EB-8FE7-53F1791B494F%7D&dist=hppr
>
> Bug reports and suggestions are very welcome.
>
> Cheers,
>
> Bob Bunge
> NWS OCIO
>
>
>
> Jack wrote:
>> I recently developed a Google Android mobile app which uses CAP  
>> feeds.
>> The coolest feature of Em-Radar is of course the delivery of CAP
>> alerts based on your GPS location.  You can see more details from
>> Google's page:
>> http://code.google.com/android/adc_gallery/app.html?id=14
>> Em-Radar works perfectly with the California EDIS CAP feed which is
>> 100% CAP compliant.
>> The big challenge facing nationwide deployment is that the current
>> NOAA CAP feeds do not include polygons, but instead uses FIPS codes.
>> I understand that NOAA is working on making their feeds fully CAP
>> compliant but I need a temporary solution now.
>> Can someone point me to a free database which I can use to convert  
>> any
>> FIPS code to a Polygon?   I will release the CAP client as a free
>> download so any database that costs money is out of the question.
>> Regards,
>> Jack
>> _______________________________________________
>> This list is for public discussion of the Common Alerting  
>> Protocol.  This list is NOT part of the formal record of the OASIS  
>> Emergency Management TC.  Comments for the OASIS record should be  
>> posted using the form at http://www.oasis-open.org/committees/comments/form.php?wg_abbrev=emergency
>> CAP-list mailing list
>> CAP-list at lists.incident.com
>> http://eastpac.incident.com/mailman/listinfo/cap-list
>> This list is not for announcements, advertising or advocacy of any  
>> particular program or product other than the CAP itself.
> _______________________________________________
> This list is for public discussion of the Common Alerting Protocol.   
> This list is NOT part of the formal record of the OASIS Emergency  
> Management TC.  Comments for the OASIS record should be posted using  
> the form at http://www.oasis-open.org/committees/comments/form.php?wg_abbrev=emergency
> CAP-list mailing list
> CAP-list at lists.incident.com
> http://eastpac.incident.com/mailman/listinfo/cap-list
>
> This list is not for announcements, advertising or advocacy of any  
> particular program or product other than the CAP itself.