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

 


Help: OASIS Mailing Lists Help | MarkMail Help

emergency-gis message

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


Subject: Re: [emergency-gis] Fwd: RE: GML & CAP


Can someone provide a non-GIS-specialist's description of the 
downward-scalability issue Neil suggests?  I'm glad Eliot's GML 
transform help solve it, but I'm trying to figure out what, if 
anything, we need do to improve the CAP message format itself.

As for referring out to other maps, is the current <resource> 
mechanism adequate or do we need to consider some sort of referencing 
from within an <area> element?  If the additional map is simply a 
reference asset then it seems like <resource> might be adequate... 
but if it's required in order to express something about a particular 
target region or sub-region for the alert, then maybe it needs to be 
a native CAP feature.

I'm afraid I'm being a little dense about what's at issue here.

- Art


At 11:54 AM -0400 8/29/03, Eliot Christian wrote:
>(This e-mail forwarded with permission of the author)
>
>>From: Briscombe Neil J <NJBRISCOMBE@qinetiq.com>
>>To: "'Eliot Christian'" <echristi@usgs.gov>
>>Subject:   RE: GML & CAP
>>Date:  Fri, 29 Aug 2003 10:55:36 +0100
>>
>>Eliot,
>>
>>Its an interesting approach. It solves the problem I had with CAP downwards
>>scalability. Through the GML bounding tags the CAP elements will be
>>absolutely determinable removing the problem of arbitrary differences that
>>occur between digital maps. Especially as map CAP elements could distributed
>>inside a map, even having different alert layers. CAP elements would also be
>>easier store and handle in a GIS this way.
>>
>>only gripe is that it still doesn't 'feel' right. I would have a CAP object
>>have a reference to two GML objects: one a parent map that was the server's
>>geographical domain of interest (e.g. a building plan which was correctly
>>bounded) and a second object that was the alert's shape. Neither would have
>>to be 'in' the CAP alert but CAP could refer out to other resources. The CAP
>>alert could also contain simple shape definition for thin clients. But by
>>pointing out to other resources you could have the benefit of say GML v3's
>>shape changing algorithm or a layer that was a history or log of shapes. If
>>the CAP alert is picked up by a simple, very thin client it could well
>>ignore the GML resources pointed to. If it was a GIS with a fat pipe to the
>>internet it would go use them. Of course one of your CAP GML layers could do
>>this anyway, I was just lobbying Art and the group trying to get something
>>into the CAP spec itself.
>>
>>What you present corrects CAP so that it can scale down to be used at the
>>granularity of a building or finer, and I would definitely consider reusing
>>your approach rather than develop my own (particularly if others adopt it).
>>The current project I am working on doesn't even call for this scalability,
>>but without it CAP would ultimately limit its applications. CAP could be
>>better used in incident response and management for example if it has the
>>scalability which you have now provided for.
>>
>>Great work, even if its not my way!
>>
>>Kind regards,
>>
>>Neil.
>>
>>  > -----Original Message-----
>>  > From: Eliot Christian [mailto:echristi@usgs.gov]
>>  > Sent: 11 August 2003 19:51
>>  > To: Briscombe Neil J
>>  > Subject: Re: GML & CAP
>>  >
>>  >
>>  > At 03:39 PM 8/11/2003 +0100, you wrote:
>>>  >Eliot,
>>>  >
>>>  >Unfortunately also replied to CAP list in the first place so
>>>  sorry if you
>>>  >have already received this message.
>>>  >
>>>  >I am extremely interested in GML CAP interoperability. I had
>>>  no attachment
>>>  >though. Please could you send to me a copy directly.
>>>
>>>  Cool--it would be very useful for someone with a GML interest to
>>>  review this!
>>>
>>>  The GML is attached, as well as my draft "Implementors Note"
>>>  about how I made this GML file from a set of CAP alert messages.
>>>
>>>  Eliot
>>>
>>>
>>
>>The Information contained in this E-Mail and any subsequent correspondence
>>is private and is intended solely for the intended recipient(s).
>>For those other than the recipient any disclosure, copying, distribution,
>>or any action taken or omitted to be taken in reliance on such information
>>is prohibited and may be unlawful.
>>
>>Emails and other electronic communication with QinetiQ may be monitored.
>>Calls to our Customer Contact Centre may be recorded for quality control,
>>regulatory and monitoring purposes.
>
>
>To unsubscribe from this mailing list (and be removed from the 
>roster of the OASIS TC), go to 
>http://www.oasis-open.org/apps/org/workgroup/emergency-gis/members/leave_workgroup.php.



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