OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

emergency message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [emergency] RE: Sample email to interested parties WRTgeo enhancements to CAP

Something like Ron suggests might make sense, although I'm not sure whether it would be most useful to model these various geospatial components as roles of a common feature or as distinct features.  

Since we're talking about syntactically and functionally different things, that might well be processed by vary different logics, might it work best to treat them as separate features, if only to maximize back-compatibility?

We could, for example, reinforce that the existing <Alert> structure describes the area impacted over the timeframe of the enclosing <Info> block, but add an optional <DistributionArea> structure for location-based routing, and maybe an optional <HazardLocation> structure for describing the place and any movement of the source of the trouble (e.g., the location of the steampipe explosion as distinct from the area closed to the public or the area to which the message needs to be distributed.)

- Art

Art Botterell, Manager
Community Warning System
Contra Costa County Office of the Sheriff
50 Glacier Drive
Martinez, California 94553
(925) 313-9603
fax (925) 646-1120

>>> "Ron Lake" <rlake@galdosinc.com> 11/21/2007 12:35 PM >>>

I will inject my two cents from the GML perspective.  In GML we rejected
the use of geometry elements as characteristics of features.  Thus we do
NOT write in GML, things like:




In order to associate a geometric figure with a feature you must have a
property that expresses the role of that geometry in the feature - hence
the above would be written:

			<gml:LineString> ... </gml:LineString>



Those implementing GML application schemas can then use any names they
want to characterize the geometry's role and correctly express

This approach to properties is used throughout GML and applies also to
the use of temporal objects.

It would be worth considering in CAP.



-----Original Message-----
From: Rex Brooks [mailto:rexb@starbourne.com] 
Sent: November 21, 2007 12:04 PM
To: Art Botterell; emergency@lists.oasis-open.org; Carl Reed OGC Account
Subject: [emergency] RE: Sample email to interested parties WRT geo
enhancements to CAP

Thanks Art,

These are all important considerations, and not easy or simple. So, 
all I can say right now is that we need to think about it, chew on 
it, discuss it and see what we can come up with.

Cheers and Happy Thanksgiving,


At 9:20 AM -0800 11/21/07, Art Botterell wrote:
>Friends -
>We may want to think a bit more about the "what" before we dive too 
>deeply into the "how."  Experience has revealed some ambiguities in 
>the semantics of the existing CAP geospatial elements, and I think 
>addressing those may help us understand better exactly what sort of 
>geospatial elements will best meet the functional requirements.
>One of those ambiguities has to do with whether the CAP Area element 
>describes the area directly affected by a hazard, the location of 
>the hazard itself, or the area to which information about the hazard 
>should be routed.  All three are legitimate topics, but they don't 
>necessarily raise the same requirements.  I'm not sure, for example, 
>that there would be any meaningful use of a line or point in 
>describing an affected area or a message-targeting area, while a 
>hazard location might be a point and a hazard in motion (see below) 
>might be described as a line or an unterminated vector.
>The temporal dimension is another aspect I'm thinking we may not 
>have addressed fully.  Currently the only formal way to describe 
>motion or trends in CAP is by means of a set of Info blocks each 
>with its own <effective> and <expires> values... in effect, a set of 
>"key frames" which might or might not imply some continual 
>transition between the described states.  I notice that NWS has 
>recently started adding motion vectors (starting location, direction 
>and rate) to its geospatial descriptions in storm warnings.
>And of course one of the long-standing requirements for CAP 
>generally is that it be easy to process on autonomous devices with 
>various kinds and degrees of connectivity.  That's why I have some 
>anxiety about the idea of supporting multiple coordinate systems... 
>do we risk making it impractical for lightweight devices to know 
>about all the possible coordinate systems?  My mind is open on that, 
>but I hope we'll keep in mind the differences between the 
>requirements for a full-blown GIS application and those for a 
>portable (e.g., wristwatch-sized) or embedded system.
>- Art
>Art Botterell, Manager
>Community Warning System
>Contra Costa County Office of the Sheriff
>50 Glacier Drive
>Martinez, California 94553
>(925) 313-9603
>fax (925) 646-1120
>>>>  "Carl Reed OGC Account" <creed@opengeospatial.org> 11/16/2007
11:44 AM >>>
>Hi All -
>We would like to get this email out to all interested CAP parties so 
>that we can collect requirements and move forward. I originally sent 
>this email in September and only heard from Rex. Other feedback 
>would be appreciated.
>Thanks and regards
>----- Original Message -----
>From: Carl Reed OGC Account
>To: emergency@lists.oasis-open.org 
>Sent: Wednesday, September 12, 2007 8:24 AM
>Subject: [emergency] RE: Sample email to interested parties WRT geo 
>enhancements to CAP
>A bit tardy :-)
>First stab at a letter to interested party to collect additional 
>requirements for geo enhancements to CAP and by extension to EDXL.
>Dear < >
>CAP has now been widely implemented. As a result, we are beginning 
>to receive considerable feedback regarding implementation 
>experience, especially in the realm of requirements for enhanced 
>capabilities to express additional (and richer) geographic elements. 
>Some suggestions have been to allow additional coordinate reference 
>systems in addition to WGS-84, the ability to encode point, line, 
>and route features, and the ability to reference the output of a 
>plume model have been suggested.
>Therefore, in order to document a consistent set of requirements for 
>potential enhancement or extensions to CAP, we are seeking your 
>input and experience. Please note that we are not seeking input on 
>how to change CAP or to implement changes in CAP. We are instead 
>seeking either use cases or new requirements for 
>using/encoding/referencing geospatial content in a CAP message.
>Thank you for your help and consideration.
>Carl Reed (CTO, OGC)
>OASIS Emergency Management TC GIS SC Chair.
>Carl Reed, PhD
>CTO and Executive Director Specification Program
>The OGC: Helping the World to Communicate Geographically
>This communication, including attachments, is for the exclusive use 
>of addressee and may contain proprietary, confidential or privileged 
>information. If you are not the intended recipient, any use, 
>copying, disclosure, dissemination or distribution is strictly 
>prohibited. If you are not the intended recipient, please notify the 
>sender  immediately by return email and delete this communication 
>and destroy all copies.
>"The important thing is not to stop questioning." -- Albert Einstein
>"Security is mostly a superstition. It does not exist in nature. 
>Life is either a daring adventure or nothing." -- Helen Keller
>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

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.  You may a link to this group and all your TCs in

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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]