[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [emergency-gis] Groups - Suggested changes for CAP 2.0 - CRS and GML (Best Practices for CRS - for OASIS.doc) uploaded
To add another quote to the mix :-) "Everything should be made as simple as possible, but no simpler." -Albert Einstein Cheers Carl ----- Original Message ----- From: "Art Botterell" <acb@incident.com> To: <emergency-gis@lists.oasis-open.org> Sent: Monday, January 31, 2005 9:47 PM Subject: Re: [emergency-gis] Groups - Suggested changes for CAP 2.0 - CRS and GML (Best Practices for CRS - for OASIS.doc) uploaded > Thanks, Carl! > > At 8:14 PM -0700 1/31/05, Carl Reed OGC wrote: >>This may all be nit-picky legalize... > > Well, maybe a bit. As you point out, the standards that matter are the > ones folks use. As a practitioner I'll confess I'm only peripherally > concerned with the niceties of CAP's formal status. > > Our goal has been... and I'd suggest, in light of the new realities of > homeland security in the U.S. and globally, should remain... to bring > workable standards to a sufficient level of stability fast enough to let > implementers start addressing our target problem-set quickly (which in the > case of CAP I think we've done)... and then to incorporate their learnings > iteratively and systematically at a tempo that encourages rather than > inhibits uptake. > >>In the geospatial technology world (remote sensing, sensor webs, location >>services, GIS, CAD and the list goes on), integration of content from many >>sources, including alerts, is a paramount requirement of many >>applications. The concepts of fusion, sharing, and integration requires >>that proper metadata and content be available. > > That's undoubtedly true, but (and please forgive my density) I'm afraid > I'm still not making the leap from that broad statement to the specifics > of what and why we should change in CAP. And I'm wondering whether this > might really be more of an EDXL discussion than a CAP issue per se. > >>The OGC members are getting ready to start an interoperability experiment >>in which CAP will be used. They will be evaluating CAP from the >>perspectives that I just mentioned. > > Great... I'm sure several folks in the TC would love to help support that! > And might it be easier to cast these proposals in specific terms once you > have the results of that exercise? > >>I am not suggesting that CAP physically support numerous CRS's. I am >>saying why not have the ability to support any CRS with WGS as a default. > > Well, as I recall our discussions, the reason the TC originally decided to > specify WGS-84 was that we didn't want to push the complexity of > interpreting multiple CRS's onto thousands or even millions of potential > consuming devices, many of them likely to be embedded systems. And we do > provide a mechanism for referencing any form of additional data, including > geospatial data, as resources to the CAP message. Maybe I'm missing the > distinction between "support" and "physically support." > >>So, let's consider some countries other than the US and what they use for >>their legal national mapping programs. This is not to say that >>implementors could not use WGS 84, but there would be pressure to use >>something else. > > Standards do involve choices. We tried to find the one most widely > acceptable and seemingly most stable CRS platform for CAP applications. > CAP was never intended to be a universal GIS "glue language"... for that > we have GML, don't we? > >>However, by adding a few optional elements, then CAP becomes a much richer >>messaging protocol that can provide much more content and context if the >>application developer so desires. > > A lot of the value of CAP comes from it being a simple core > info-structure... so I'm not sure "rich" is automatically a virtue in our > particular application environment. > > Thirty spokes join together in the hub. > It is because of what is not there that the cart is useful. > Clay is formed into a vessel. > It is because of its emptiness that the vessel is useful. > Cut doors and windows to make a room. > It is because of its emptiness that the room is useful. > Therefore, what is present is used for profit. > But it is in absence that there is usefulness. > > Or as we westerners say, "beware of mission creep." > > But again, I see no problem with considering specific proposals to achieve > specific benefits in line with CAP's defined goals. Or with considering > other standards we might be able to develop within EDXL to meet > GIS-related requirements beyond the particular focus of CAP. > > - Art > > 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]