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" <>
To: <>
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.
>
>
