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 - CRSand GML (Best Practices for CRS - for OASIS.doc) uploaded

Friends -

Is it possible we're being drawn into a battle that's not our own? 
I'm not still clear that any of this poses any actual problem for the 
CAP implementer community.  And a global discussion of the relative 
merits of CRS's seems well beyond the scope of CAP.  Clarifying 
ambiguities is one thing, getting embroiled in other standards 
groups' issues is another.

Anyway, I'm not sure a normative specification document is the right 
place for extended narrative about each of the TC's choices... for 
that we have the TC and SC records, in the form of our email and 
document archives.  And the TC certainly can publish separate 
whitepapers if we think it useful... although on this topic it seems 
like the OGC would be the more appropriate source.

In any event, I'm increasingly persuaded that this discussion, to 
whatever extent it's useful, needs to be framed in the larger context 
of EDXL and not just CAP.

- Art

At 9:21 AM -0700 2/1/05, Carl Reed OGC wrote:
>Dave -
>Yes, that is why I am suggesting (and provided in document) a 
>lengthy informative section on WGS-84 (From NGA documents).
>----- 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.
>>David M. Danko
>>GIS Standards
>>Environmental Systems Research Institute, Inc.
>>8620 Westwood Center Drive
>>Vienna, VA 22182-2214
>>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
>>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
>>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
>>To unsubscribe from this mailing list (and be removed from the 
>>roster of the OASIS TC), go to 
>To unsubscribe from this mailing list (and be removed from the 
>roster of the OASIS TC), go to 

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]