OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

emergency-gis message

[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 



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