[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [emergency] Groups - EDXL/CAP Routing Concepts and Issues(OASIS Input of Routing Concepts IEPD Version 0.4.pdf)uploaded
Hi, I don't disagree with that - it is just a question of being able to be more accurate in expressing the semantics of Area in the CAP protocol - it seems this issue has come up before .. R -----Original Message----- From: Lee Tincher [mailto:ltincher@evotecinc.com] Sent: November 30, 2007 2:10 PM To: 'Art Botterell'; Ron Lake; emergency@lists.oasis-open.org; dellis@sandia.gov Subject: RE: [emergency] Groups - EDXL/CAP Routing Concepts and Issues(OASIS Input of Routing Concepts IEPD Version 0.4.pdf)uploaded I am in complete agreement with Art's statement below - this should be a DE function.... Thanks, Lee 'We the unwilling, led by the unknowing have been doing the difficult with little for so long that we are now ready to tackle the impossible with nothing.' -- Local Fire communications reserve volunteer motto -----Original Message----- From: Art Botterell [mailto:ABott@so.cccounty.us] Sent: Friday, November 30, 2007 4:59 PM To: rlake@galdosinc.com; emergency@lists.oasis-open.org; dellis@sandia.gov Subject: Re: [emergency] Groups - EDXL/CAP Routing Concepts and Issues(OASIS Input of Routing Concepts IEPD Version 0.4.pdf)uploaded Even before that there's the question of whether routing information, as distinct from hazard-descriptive information, belongs in CAP at all. Maybe, as was suggested earlier, routing should be handled in the DE instead. I think that might make sense, since any routing directive that's different from the hazard area is an artifact of some policy or infrastructure constraint that may well come from some entity other than the originator. If we put such third-party instructions in the CAP structure itself, that could force a lot of avoidable re-signings of the core message. (Plus it would create an unnecessary duplication of function with the DE.) - Art -----Original Message----- From: "Ron Lake" <rlake@galdosinc.com> To: <emergency@lists.oasis-open.org> To: <dellis@sandia.gov> Sent: 11/30/2007 12:47:47 PM Subject: RE: [emergency] Groups - EDXL/CAP Routing Concepts and Issues (OASIS Input of Routing Concepts IEPD Version 0.4.pdf) uploaded Hi, This speaks to the need to have a property concept (as in GML) that expresses the role of the geometry (area) in relation to the feature (event) of interest. This would deal directly with the question raised. In GML one would make use of a property name something as follows: <abc:Alert gml:id="p1454"> <abc:impactArea> .. polygon .. </abc:impactArea> <abc:alertArea> ... polygon ... </abc:alertArea> </abc:Alert> Cheers R -----Original Message----- From: dellis@sandia.gov [mailto:dellis@sandia.gov] Sent: November 30, 2007 12:21 PM To: emergency@lists.oasis-open.org Subject: [emergency] Groups - EDXL/CAP Routing Concepts and Issues (OASIS Input of Routing Concepts IEPD Version 0.4.pdf) uploaded The document named EDXL/CAP Routing Concepts and Issues (OASIS Input of Routing Concepts IEPD Version 0.4.pdf) has been submitted by David Ellis to the OASIS Emergency Management TC document repository. Document Description: The current CAP standard requires the use of the "area" and sub elements to be the union of all Area blocks. This raises a problem for systems which actual do GeoSpatial and GeoPolicitcal (Jurisdictional) routing of CAP messages. The lack of ability to label one area block as the "true" area for alerting target population AOW (headline, instruction etc.) and another area block as the time evolving plume from a "Hazmat" event (AOH) makes meaningful use of CAP standard very difficult. View Document Details: http://www.oasis-open.org/apps/org/workgroup/emergency/document.php?docu ment _id=26274 Download Document: http://www.oasis-open.org/apps/org/workgroup/emergency/download.php/2627 4/OA SIS%20Input%20of%20Routing%20Concepts%20IEPD%20Version%200.4.pdf PLEASE NOTE: If the above links do not work for you, your email application may be breaking the link into two pieces. You may be able to copy and paste the entire link address into the address field of your web browser. -OASIS Open Administration --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. You may a link to this group and all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]