[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [emergency-gis] Fwd: RE: GML & CAP
Since we have already voted to go to Committee Specification status and have our 30-day public comment review period, I suggest we put this off until we get started on that, and include it in there, if it actually fits there. This sounds like a lot more work than we should be devoting to this now. We can ask for more specific explanations in the course of the public comment process. Yes, we should pay attention to this. Yes we should attempt to build the best spec we can. Yes we should make it as interoperable as possible. Every group goes through this last second and just after the last second suggestion or set of suggestions. And, at some point, every group has to just say, okay, enough, let's move on and look at this once we have more experience under our belts. BTW, this sounds more like a 2.0 issue, more than a readjustment during the public comment period or 1.1 bug fixes. This is an additional design requirement, and I, for one, am not sure CAP is where this consideration belongs. I have a suspicion that Neil is not fully aware that CAP is just the first spec we will be working on, and is essentially low-hanging fruit which it is convenient to wrap up before we get into designing further specs from scratch. I think this may be an "Infrastructure" or architecture issue more than clearing away the brush of miscellany in the arena of immediate first response mechanisms. Ciao, Rex At 9:33 AM -0700 8/29/03, Art Botterell wrote: >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. > > >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. -- Rex Brooks GeoAddress: 1361-A Addison, Berkeley, CA, 94702 USA, Earth W3Address: http://www.starbourne.com Email: rexb@starbourne.com Tel: 510-849-2309 Fax: By Request
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]