OASIS Emergency Management TC

  • 1.  [OASIS Issue Tracker] (EMERGENCY-29) Single text field that summarizes multiple area descriptions

    Posted 05-09-2015 03:43
    [ https://issues.oasis-open.org/browse/EMERGENCY-29?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=59574#comment-59574 ] Nuwan Waidyanatha commented on EMERGENCY-29: -------------------------------------------- We intend to apply the same method as Canada for the new implementations in the Maldives and the Philippines. Using risk assessment technique to first develop a set of predefined alert areas with respective polygons for them. Then make them available for alert issuer to select. My concern is with filtering long lists to select the appropriate one. My thinking is that these predefined alert areas can be tagged by hazard and severity (e.g. 5 year flood, 10 year flood, 100 year flood). May investigate relating these predefined alert areas with the eventCode as well. Any other suggestions to implement such? > Single text field that summarizes multiple area descriptions > ------------------------------------------------------------ > > Key: EMERGENCY-29 > URL: https://issues.oasis-open.org/browse/EMERGENCY-29 > Project: OASIS Emergency Management TC > Issue Type: Improvement > Components: CAP > Reporter: Steve Hakusa > > Extracted from https://issues.oasis-open.org/browse/EMERGENCY-10 after a discussion in the CAP-SC meeting on August 20. > In the case a CAP message has multiple <area> blocks, it would be quite useful to define a single field that succinctly summarized all of the areas. > For example, we frequently see alerts with a long list of <area> blocks that correspond to existing political boundaries (zip codes, counties, warning zones) rather than defining the alertable area in a single polygon. In these cases, each <area> block has an <areaDesc> that describes that area. There is no field, then that summarizes the long list of areas to a single string. > As an example, NWS creates a severe winter storm alert with 5 <area> blocks, each with a geocode of a county in or around Atlanta. I'm looking for a single, optional field like > <areaDesc>Atlanta Metro Area</areaDesc> > or > <areaDesc>Northern Georgia</areaDesc> > It may be argued that CAP already supports what I'm looking for, if only NWS in this case used a single <area> block instead of 5. > Art Botterell comments on https://issues.oasis-open.org/browse/EMERGENCY-10: > """ > By the same token, if the multiple areas can be described by a single label, they probably should be a single Area. In other words, I'm thinking we should look to help originators make better use the existing <areaDesc> field before asking them to populate another, potentially redundant element. > And of course having redundancy or semantic overlap among fields is almost always a bad thing in the structured-data context because it raises the problem of what to do if the two values conflict. > """ > If that is the argument, then this issue becomes roughly the same as issue 10: What if a CAP author wants/needs to provide multiple granularities of area description (name *both* the counties and the metro area) in a single CAP alert? -- This message was sent by Atlassian JIRA (v6.2.2#6258)


  • 2.  Re: [emergency] [OASIS Issue Tracker] (EMERGENCY-29) Single text field that summarizes multiple area descriptions

    Posted 05-09-2015 19:32
    Seems there might be a larger issue that needs addressing here, which is the resolution / dereferencing of pre-designated areas by name from some external source. Binding a-priori geometries to CAP, a CAP profile or a CAP implementation seems like an encapsulation failure that could result in difficulties and inconsistencies as hazards emerge and evolve, land use patterns change and so on. From time to time over the years the need for a geospatial “gazetteer” function that would allow namespacing of area designations by source, a bit like the valueName/value approach used in the past to allow reference to externally-maintained dictionaries. I wonder whether something like OGC Web Feature Services might be applied here? - Art > On May 8, 2015, at 20:43, OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org> wrote: > > > [ https://issues.oasis-open.org/browse/EMERGENCY-29?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=59574#comment-59574 ] > > Nuwan Waidyanatha commented on EMERGENCY-29: > -------------------------------------------- > > We intend to apply the same method as Canada for the new implementations in the Maldives and the Philippines. Using risk assessment technique to first develop a set of predefined alert areas with respective polygons for them. Then make them available for alert issuer to select. > > My concern is with filtering long lists to select the appropriate one. My thinking is that these predefined alert areas can be tagged by hazard and severity (e.g. 5 year flood, 10 year flood, 100 year flood). May investigate relating these predefined alert areas with the eventCode as well. Any other suggestions to implement such? > >> Single text field that summarizes multiple area descriptions >> ------------------------------------------------------------ >> >> Key: EMERGENCY-29 >> URL: https://issues.oasis-open.org/browse/EMERGENCY-29 >> Project: OASIS Emergency Management TC >> Issue Type: Improvement >> Components: CAP >> Reporter: Steve Hakusa >> >> Extracted from https://issues.oasis-open.org/browse/EMERGENCY-10 after a discussion in the CAP-SC meeting on August 20. >> In the case a CAP message has multiple <area> blocks, it would be quite useful to define a single field that succinctly summarized all of the areas. >> For example, we frequently see alerts with a long list of <area> blocks that correspond to existing political boundaries (zip codes, counties, warning zones) rather than defining the alertable area in a single polygon. In these cases, each <area> block has an <areaDesc> that describes that area. There is no field, then that summarizes the long list of areas to a single string. >> As an example, NWS creates a severe winter storm alert with 5 <area> blocks, each with a geocode of a county in or around Atlanta. I'm looking for a single, optional field like >> <areaDesc>Atlanta Metro Area</areaDesc> >> or >> <areaDesc>Northern Georgia</areaDesc> >> It may be argued that CAP already supports what I'm looking for, if only NWS in this case used a single <area> block instead of 5. >> Art Botterell comments on https://issues.oasis-open.org/browse/EMERGENCY-10: >> """ >> By the same token, if the multiple areas can be described by a single label, they probably should be a single Area. In other words, I'm thinking we should look to help originators make better use the existing <areaDesc> field before asking them to populate another, potentially redundant element. >> And of course having redundancy or semantic overlap among fields is almost always a bad thing in the structured-data context because it raises the problem of what to do if the two values conflict. >> """ >> If that is the argument, then this issue becomes roughly the same as issue 10: What if a CAP author wants/needs to provide multiple granularities of area description (name *both* the counties and the metro area) in a single CAP alert? > > > > -- > This message was sent by Atlassian JIRA > (v6.2.2#6258) > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >


  • 3.  Re: [emergency] [OASIS Issue Tracker] (EMERGENCY-29) Single text field that summarizes multiple area descriptions

    Posted 05-09-2015 20:19
    Art - Great question! Check out the OGC WFS Gazetteer profile: https://portal.opengeospatial.org/files/?artifact_id=46964 Consistent with relevant ISO standards (such as for spatial metadata) and harmonized with requirements and use cases from NGA, USGS and a variety of partner organizations such as the State of Montana. The NGA server instance is here: http://directory.spatineo.com/service/12961/ Implemented by numerous vendors (proprietary and open source). More recently, OGC interoperability test beds have explored gazetteer federation: https://portal.opengeospatial.org/files/?artifact_id=59336 Abstract: The Virtual Global Gazetteer integrates two gazetteers – a copy of the USGS gazetteer containing domestic names (hosted by Compusult) and a copy of the NGA gazetteer containing non-domestic names (hosted by Interactive Instruments) and provides the capability to link to additional local gazetteers and linked data information, allowing a user to retrieve extended information on locations selected from either of the initial gazetteers. Cheers Carl


  • 4.  Re: [emergency] [OASIS Issue Tracker] (EMERGENCY-29) Single text field that summarizes multiple area descriptions

    Posted 05-09-2015 22:59
    Thanks, Carl. At the same time we’ll want to bear in mind the basic design constraint that not all alerting devices that may consume CAP alerts will necessarily have Internet connectivity, even though they may have location awareness by way of GPS/GLONASS. Therefore, we may want to guard against the temptation posed by having a-priori named alerting areas, which is that originators (or implementers of origination tools) may attempt a shortcut by substituting area references by name (geocodes) for explicit geospatial geometries in the CAP alert <area> block. Any receivers that don’t have guaranteed access to the latest edition of the gazetteer will need the actual lat/lon coordinates to evaluate a CAP message's targeting. That suggests that the translation from a named, pre-determined alerting area to the corresponding geospatial coordinates should be done in the originating tool. No change to the CAP specification or profile would be necessary, only the creation of a new utility to provide this convenience to the originating users. Possibly an opportunity for forging a functional partnership between origination tool developers and the disaster GIS community. The gazetteer function Carl describes might be a new feature that Usihidi could consider adding. Of course none of this changes the function of the existing <areaDesc> field, which should provide a human-comprehensible summary of the alert area. Seems like we’re really talking about origination-tool convenience features here. - Art > On May 9, 2015, at 13:18, Carl Reed <creed@opengeospatial.org> wrote: > > Art - > > Great question! Check out the OGC WFS Gazetteer profile: https://portal.opengeospatial.org/files/?artifact_id=46964 > > Consistent with relevant ISO standards (such as for spatial metadata) and harmonized with requirements and use cases from NGA, USGS and a variety of partner organizations such as the State of Montana. The NGA server instance is here: http://directory.spatineo.com/service/12961/ > > Implemented by numerous vendors (proprietary and open source). > > More recently, OGC interoperability test beds have explored gazetteer federation: > > https://portal.opengeospatial.org/files/?artifact_id=59336 > > Abstract: The Virtual Global Gazetteer integrates two gazetteers – a copy of the USGS gazetteer containing domestic names (hosted by Compusult) and a copy of the NGA gazetteer containing non-domestic names (hosted by Interactive Instruments) and provides the capability to link to additional local gazetteers and linked data information, allowing a user to retrieve extended information on locations selected from either of the initial gazetteers. > > Cheers > > Carl > >