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: Fwd: RE: GML & CAP


(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.



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