[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [emergency] RE: Recent CBRN Interoperability for Situational Awareness Workshop
Thanks Lee, Gary, Gary nailed it. I hope that the message gets forwarded to the appropriate folks. I agree with Lee that we need to take it up in the TC and see what we can do to help the Adoption SC develop the materials to help educate our audience better than we have so far. We've had some good suggestions in that regard in the course of this discussion, too, and I'm glad to see that happen. Cheers, Rex At 10:26 PM -0500 11/18/08, Lee Tincher wrote: >I am so happy to hear this response. We have been dealing with this exact >same issue from a different discipline. I have not had success in getting >support of the multiple bodies in a DE from that effort - in fact I have >caused a great deal of delay in the effort by trying to establish that >approach. > >I suggest that we take this into the next EM-TC level meeting and discuss >the options we may have in promoting (or discussing the merits of) this >approach. This is excessively important to multiple large scale efforts >being currently worked on! > >Thanks, >Lee > >Action springs not from thought, but from a readiness for responsibility. - >Dietrich Bonhoeffer > > >-----Original Message----- >From: Gary Ham [mailto:hamgva@cox.net] >Sent: Tuesday, November 18, 2008 9:47 PM >To: creed@opengeospatial.org; 'Rex Brooks' >Cc: 'Jacob Westfall'; emergency@lists.oasis-open.org; 'Lee Tincher'; 'Art >Botterell'; gpercivall@opengeospatial.org; rsingh@opengeospatial.org >Subject: RE: [emergency] RE: Recent CBRN Interoperability for Situational >Awareness Workshop > >Carl, > >The DE has the ability to contain SensorML as a payload and has the >appropriate structures that allow it to be intelligently routed as >necessary. The SensorML itself would stay undisturbed. No sense >reinventing the wheel. My thought is that sensor readings are generally not >public alerts in the more conventional CAP sense. They are sensor reading >that might trigger CAP alerts. The DE is designed to provide a wrapper for >any emergency information. The wrapper it provide for a geographic target >"area of interest", characterization of the content in a variety of ways, >and identification of the content. The content itself stays pure inside the >distribution wrapper. That content can be pure SensorML, pure CAP, pure >Resource, pure HAVE, pure HL7, or even proprietary. In fact multiple >contents of different kinds can be put into the same wrapper and send >together if desired. > >The DE target area does, in a future release, need to become a >geo-oasis:where. It is currently the same structure as CAP, but it can >contain any standard GML as content quite easily. Even without change. > >R/s > >Gary A. Ham >http://grandpaham.com >703-899-6241 >Grandpa can do IT! > > >-----Original Message----- >From: creed@opengeospatial.org [mailto:creed@opengeospatial.org] >Sent: Tuesday, November 18, 2008 6:48 PM >To: Rex Brooks >Cc: Jacob Westfall; emergency@lists.oasis-open.org; Lee Tincher; 'Art >Botterell'; creed@opengeospatial.org; gpercivall@opengeospatial.org; >rsingh@opengeospatial.org >Subject: Re: [emergency] RE: Recent CBRN Interoperability for Situational >Awareness Workshop > >Apologies - but being a bit of a slacker WRT EDXL-DE, I was wondering if >the DE elements for sensors have been aligned (harmonized) with the OGC >SWE standards baseline concepts, taggage, etc. Reason I ask is that there >will soon be a registry of sensor descriptions (metadata, processes, etc) >using SensorML. These SensorML files have been or are being defined for >all NASA satellites, a number of UAV's, many classified sensor systems, >most aerial digital cameras, just about all of the ocean sensors, and >already a number of weather sensor types. I would hate to duplicate work >or have competing methods for describing a sensor. > >Carl > >> Hi Jacob, >> >> These are the questions we need to discuss. My personal opinion is >> that we should start with the issues surfaced in the CAP-NextGen >> Comments, and include the specific concern from Carl Reed's earlier >> message this morning "... CAP implementations in this community are >> doing a variety of interesting additions (such as embedding sensor >> metadata) that will make the implementations non-interoperable. ..." >> >> We gave EDXL-DE the capability to handle 4 kinds of sensor >> information as distributionTypes: >> Sensor Configuration; >> SensorControl; >> SensorStatus; and >> SensorDetection. >> >> So, I think we need to create guidance-education-usage notes for >> EDXL-DE and CAP simultaneously for this particular issue. Developing >> clear examples for this issue and the others we address in these >> notes is, in my opinion, key to helping our audience understand how >> to apply the specifications. >> >> Cheers, >> Rex >> >> At 10:49 AM -0500 11/18/08, Jacob Westfall wrote: >>> > mechanisms focused on particular issues would be helpful. As Art >>>> notes, we may eventually see patterns develop that we can incorporate >>>> in a more comprehensive document if we think that's best. >>> >>>So instead of a sensor profile, or single best practices guide, >>>create a number of "application notes" or "usage guides"? What >>>would these guides be called and the topics be? Is this something >>>Adoption might want to ask for comments/feedback on from the CAP >>>community in order to develop a list? >>> >>>-- >>>jake@jpw.biz >>>-- >>> >>>--------------------------------------------------------------------- >>>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 >> >> >> -- >> Rex Brooks >> President, CEO >> Starbourne Communications Design >> GeoAddress: 1361-A Addison >> Berkeley, CA 94702 >> Tel: 510-898-0670 >> >> --------------------------------------------------------------------- >> 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 >> >> > > > >--------------------------------------------------------------------- >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 > > >--------------------------------------------------------------------- >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 -- Rex Brooks President, CEO Starbourne Communications Design GeoAddress: 1361-A Addison Berkeley, CA 94702 Tel: 510-898-0670
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]