Re: [emergency-gis] Groups - Suggested changes for CAP 2.0 - CRS and GML (Best Practices for CRS - for OASIS.doc) uploaded

["Carl Reed OGC" <creed@opengeospatial.org>]

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