[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]