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

Dave -

Yes, that is why I am suggesting (and provided in document) a lengthy 
informative section on WGS-84 (From NGA documents).

Regards

Carl

----- Original Message ----- 
From: "David Danko" <DDanko@esri.com>
To: "Art Botterell" <acb@incident.com>; <emergency-gis@lists.oasis-open.org>
Sent: Tuesday, February 01, 2005 9:19 AM
Subject: RE: [emergency-gis] Groups - Suggested changes for CAP 2.0 - CRS 
and GML (Best Practices for CRS - for OASIS.doc) uploaded


> Let's not forget the Professional Surveyor article I sent out last year by
> Cliff Mugnier who was concerned about the US Army (and his son) in
> Afghanistan using bad coordinate transformation parameters and friendly
> fire. His fears were allayed when he learned from NGA that they always 
> used
> WGS 84. An excerpt:
> There are warfighters and there is the Department of Defense (DoD) in
> general. Warfighters always have positional detail exclusively referenced 
> to
> the World Geodetic System 1984 (WGS84). The maps, the imagery, the
> coordinates, everything available to a warfighter is referenced to the 
> WGS84
> and nothing but. Transformation software is distributed for the Department
> of Defense use in research applications, for building simulators, foreign
> aid, cartographic analyses, cartometric evaluations, etc. -geodetic
> transformation software is not ever intended for the warfighter.
>
> Perhaps the next version of CAP should have more explanation of why we're
> using WGS 84.
>
> Dave
>
> David M. Danko
> GIS Standards
> Environmental Systems Research Institute, Inc.
> 8620 Westwood Center Drive
> Vienna, VA 22182-2214
> USA
> E-mail: ddanko@esri.com
> Tel: 703-506-9515 x 8011
> Mobile: 703-989-1863
> Fax: 703-506 9514
> -----Original Message-----
> From: Art Botterell [mailto:acb@incident.com]
> Sent: Monday, January 31, 2005 11:48 PM
> To: emergency-gis@lists.oasis-open.org
> 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_wor
> kgroup.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.
>
>