Question regarding use of WGS84 reference system in CAP standard [SEC=UNCLASSIFIED]

Thanks Don, Carl, Everyone,
I think Don has encapsulated the problem succinctly. We have a set
of tasks laid out here that I think are growing increasingly
inescapable. This kind of problem definition is necessary if we are
going to succeed in both writing usable standards and in engaging
our audiences in a pro-active collaboration for successful adoption.
Unfortunately this is a terrifically difficult set of tasks to
address, so we need more thinking along the lines of the explanatory
articles Greg has written describing the rationale behind the
Australian Profile.
Fortunately, now that we are seeing the problem more clearly, we
ought to be able to take on this education task more successfully,
or at least with a better chance of success. It isn't going to get
easier.
Cheers,
Rex
On 11/21/11 10:29 PM, McGarry, Donald P. wrote:
Carl-
Thanks...glad to see my comments have sparked some
conversation :). I think what is interesting here is that
we might be taking different views about the scope of the
cap standard itself. I'm thinking of the schema that oasis
produces as a  hard and fast  view...e.g. the standard
produced by oasis should define all use for  over the
wire  while your approach is more that the cap standard
defines an overall structure with flexibility for
localization  with some defaults.  Your approach seems to
imply that each region or exchange group would need to
define their own profile for use.  I don't see this as a
bad thing and frankly the more I am involved in  big
standards  the more I think this is simply the approach we
need to take to make standards that can be international
in scope.  This isn't the approach taken by folks in the
DoD (at least for their successful standards), but the DoD
world allows for strict definition of use.
I
think the problem that we are in now is that we are
trying to do things a little each way.  What I mean is
that we are trying to produce a hard and fast standard,
but include flexibility, not admitting that each region
creating their profile is something that they just need
to do.  This hasn't been as much of an issue with CAP as
I think it has been with some of the other EDXL
standards (I would point to the valuelist as an example
– it is a powerful data object, but requires parties to
agree ahead of time on terminology lists to use).
I
guess I still have two thoughts / concerns:
If
we want to take what I see as your approach…how do we
communicate the need to create region / country
specific profiles to decision makers?  E.g. In the US
how do we explain to DHS that they need to take
ownership of creating a profile of EDXL for use in the
US?  Granted this happened with the IPAWS profile for
CAP, but I think this was more of a necessity of the
IPAWS program itself rather than DHS acknowledging the
need to take ownership of a US version of a set of
standards for information sharing.  My fear with your
approach is that decision makers will continue to say
just use EDXL  in commentary without realizing the
additional work that needs to be done to make that
happen.  I see this as a problem right now and am
concerned that the implied use of profiles would only
make this worse.  Granted, this whole  problem  is not
a technology problem, but one I think OASIS needs to
address.
When
I look over the spectrum of  standards  I see a mix of
things.  You mentioned things like GeoRSS / DHCP
location / HELD.  My thought is – for the tools I use
to process GeoRSS (for example), what would they do if
I threw a non-WGS84 coordinate at it?  Not that this
is a problem with the standard, but a question about
how well tools actually handle this flexibility in
real life?  That being said, GeoRSS is a great example
since it is lightweight, flexible, and has huge use.
 It was able to get that broad implementation while
still maintaining some degree of flexibility.  On the
other hand, if you look back to  proven / enduring
standards like SMTP, HTTP, TCP, etc. there isn't a
whole lot of flexibility in the structured / control
data in those standards.  Fields and possible values
are clearly defined without a whole bunch of room for
flexibility.  Those standards have endured the test of
time to some degree.  That being said, all of those
standards are lower level than the  above layer
7 stuff we are talking about, so perhaps that
methodology doesn't apply.
So I
guess my thoughts are that although I still see setting
every field to a CRS / UOM / etc. as ideal for
developers / m2m interoperability, it may not be
feasible for international data standards.  That being
said, I think we need to do a better job of
communicating the need & role of profiles for use of
the EDXL standards.
Thoughts?
:-)

Don McGarry
The MITRE Corp.

(703) 595-9375
From:  Carl Reed < 
>
Date:  Mon, 21 Nov
2011 16:34:52 -0700
To:
McGarry, Donald
P.  <  >,
'Gary Ham' < 
>
Cc:  Pete O'Dell <  >,
Lewis Leinenweber <  >,
Darrell O'Donnell <  >,
Trott, Gregory  <  >,
Elysa Jones <  >,
<  >,

< 
>
Subject:  Re:
[emergency] Question regarding use of WGS84 reference system
in CAP standard [SEC=UNCLASSIFIED]
Don -

Interesting. I understand concern about additional
complexity. I have worked numerous standards (DHCP
location, HELD, geoURI, GeoRSS, open GeoSMS) in which
brevity and ease of implementation are paramount. All
of these state that WGS84 is the default CRS. However,
most all of them also allow for the ability to an
express alternative CRS. Reasons vary based on the
community of practice – such as national requirements,
special domain requirements, planetary CRS and so
forth.

I disagree that
“  If you opt for #1,
every system that needs to process the
geo-data in a message to do machine to machine
(m2m) messaging needs to know about all
possible formats and do a conversion to the
format it will process the message in (to do
geo routing, display, etc.).”
If one allows for an
optional CRS element in CAP, this does
not add complexity or additional formats
to worry about. The default is still
WGS84 – just like KML or GeoRSS. I would
suspect the majority of folks would
continue to use WGS84 and the default
UoM.  However, if a CRS element is
provided, then another CRS is being
specified. The CRS should most likely be
an EPSG code. There is an EPSG online
registry. Simple and easy to use.

Which brings
me back to communities of practice. Isn’t this
what the CAP profile work is all about? If a
community decides not to use WGS-84 and some other
CRS, then there is agreement in that community and
all the implementing software abides by that
agreement for that community. Interoperability is
maintained.

In the OGC we
run into community of practice or domain
requirements all the time. The way to insure
interoperability within the domain or CiP is to
have agreements on implementation best practice,
just as is happening with CAP. Also,
interoperability between domains can actually be
enhanced by allowing explicit _expression_ of CRS
and UoM metadata.

Finally, as to
the (n-1)! combinations issue, there are an
amazing array of commercial and open source
solutions for coordinate transformations. No need
to write one from scratch!  Check out Blue Marble
(commercial) or GeoAPI (open source). Many, many
others.

Cheers

Carl
From:
McGarry, Donald P.
Sent:  Monday, November 21, 2011 12:29
PM
To:
Gary Ham  ;
Carl Reed
Cc:
Pete O'Dell  ;
Leinenweber, Lewis  ;
Darrell O'Donnell  ;
Trott, Gregory  ;
Elysa Jones  ;

;

Subject:  RE: [emergency] Question
regarding use of WGS84 reference system in CAP
standard [SEC=UNCLASSIFIED]

I have some thoughts on
this…

We need to distinguish what
goes out over the wire versus what is displayed
to the user.
As Carl points out there
are two approaches:
1.
Allow multiple Coordinate
systems / units of measure to be sent out over
the wire
2.
Only allow one CRS / UOM on
the wire

If you opt for #1, every
system that needs to process the geo-data in a
message to do machine to machine (m2m) messaging
needs to know about all possible formats and do
a conversion to the format it will process the
message in (to do geo routing, display, etc.).
IMO, this places a huge burden on the developer
to handle a bunch of different cases.  In turn
this can “break” interoperability because if a
CRS / UOM is transmitted to a system that it
doesn’t know how to handle it will drop the
message on the floor.  We run into this issue
all the time with “flexible” message formats
that allow for things like height to be in MSL,
HAE, etc.  To be frank, flexibility for the
actual message over the wire is a lot of extra
work for developers which leads to lack of
adoption of a standard for m2m messaging.

If you opt for #2 (which is
currently what we do)….Everyone knows what to
expect on the wire.  In a m2m messaging system,
what goes out over the wire * should * NOT
matter to the end system consumers as the
message processors can convert CRS / UOM to meet
local needs.  To me this is much preferred.  The
reason is that if I just want to use one CRS I
either use the default, or do one conversion.
If there are “n” number of possibilities and we
are using approach #1…then I have to handle
(n-1)! (that’s factorial) cases for conversion
which is a lot of work…

All that being said, I
would be interested to hear others thoughts on
this.
Thanks,
-Don

703-595-9375
From:

[ mailto: ]
On Behalf Of  Gary Ham
Sent:  Monday, November 21, 2011 2:03
PM
To:  Carl Reed
Cc:  Pete O'Dell; Leinenweber, Lewis;
Darrell O'Donnell; Trott, Gregory; Elysa
Jones;
 ;

Subject:  Re: [emergency] Question
regarding use of WGS84 reference system in
CAP standard [SEC=UNCLASSIFIED]

Not if the messages are
signed.  The data could then not be changes
without invalidating the signature.  Changed
messages are new messages. The basic message
cannot be changed, although what the user sees can
be changed as needed.


Gary Ham
http://grandpaham.com
703-899-6241



On Nov 21, 2011, at 1:45
PM, Carl Reed wrote:
Providing the ability to
specify additional coordinate
reference systems would not change
any of the existing implementations.
Any code necessary to check for
additional CRSs would be trivial.
And any actual coordinate
conversions should happen on the
server side where the alerts are
generated and not on the client side
(although many clients now also
support easy access to coordinate
transformations.)

Regards

Carl
From:

Pete O'Dell
Sent:

Monday,
November 21, 2011 11:19 AM
To:

Leinenweber, Lewis    ;    Carl Reed    ;    Darrell O'Donnell    ;    Trott, Gregory
Cc:

Elysa Jones    ;        ;    
Subject:

RE:
[emergency] Question regarding
use of WGS84 reference system
in CAP standard
[SEC=UNCLASSIFIED]

I’m
not sure I’m following and
understanding all the different
technical threads.

From
a usability standpoint, the planet
is shrinking (digitally) and many
people/organizations in many
countries want to be able to
consume alerts that are relevant
to their global organizations
outside of physical country
boundaries.

Any
resolution to this issue that is
transparent to the  alert
recipient without an incredible
amount of additional code and
business rule processing to
resolve differences between the
various coordinate systems being
used would be appreciated and help
this objective long term.  CAP has
been an incredible purveyor of
information.
From:

     [mailto:]     On Behalf Of    Leinenweber,
Lewis
Sent:    Monday,
November 21, 2011 12:50 PM
To:    Carl
Reed; Darrell O'Donnell;
Trott, Gregory
Cc:    Elysa
Jones;     ;    
Subject:    RE:
[emergency] Question regarding
use of WGS84 reference system
in CAP standard
[SEC=UNCLASSIFIED]

Darrell, Carl
et.al. –
I would like
to add some additional thoughts to
the discussion regarding the
ability to support coordinate
reference systems in EDXL
messages.

A new, soon
to be released, OASIS Committee
Specification Draft (CSD) called
EDXL GML Simple Features profile
(EDXL-GSF), based on OGC and ISO
international standard
location-based GML schema, allows
one to specify and use any known
coordinate reference system (CRS)
for a given location. Thus, while
the default CRS may be WGS84, a
CAP message, for example, using
EDXL-GSF profile for location
geometry (point, polygon,
envelope, etc), could contain
locations using GDA94 with clarity
and without ambiguity. For
additional details and description
see the documentation excerpts
from the EDXL-GSF profile schema
(and by reference, also GML 3.2.1
standard schema) provide the
description of its use in
practice.

The purpose
of the EDXL-GSF profile is to
provide a standards-based way to
provide location information in a
message. To incorporate use of
EDXL-GSF profile would, of course,
require each EDXL message standard
Subcommittee to review and
consider the path to achieve
integration of this supporting
standard (when it is eventually
published).

edxl-gsf-base.xsd
(ref GML schema:
geometryBasic0d1d.xsd):

----------------------------------

pos -->
DirectPositionType:

--------------

“Direct
position instances hold the
coordinates for a position within
some coordinate reference system
(CRS). Since direct positions, as
data types, will often be included
in larger objects (such as
geometry elements) that have
references to CRS, the srsName
attribute will in general be
missing, if this particular direct
position is included in a larger
element with such a reference to a
CRS. In this case, the CRS is
implicitly assumed to take on the
value of the containing object's
CRS. If no srsName attribute is
given, the CRS shall be specified
as part of the larger context this
geometry element is part of,
typically a geometric object like
a point, curve, etc.”

posList
--> DirectPositionListType:

--------------

“posList
instances (and other instances
with the content model specified
by DirectPositionListType) hold
the coordinates for a sequence of
direct positions within the same
coordinate reference system (CRS).
If no srsName attribute is given,
the CRS shall be specified as part
of the larger context this
geometry element is part of,
typically a geometric object like
a point, curve, etc.  The optional
attribute count specifies the
number of direct positions in the
list. If the attribute count is
present then the attribute
srsDimension shall be present,
too. The number of entries in the
list is equal to the product of
the dimensionality of the
coordinate reference system (i.e.
it is a derived value of the
coordinate reference system
definition) and the number of
direct positions.”

----------------------------------

Hope this
helps and doesn’t muddy the waters
of the discussion.

Lew
Leinenweber
SE
Solutions, Inc.
301.351.4485
From:

     [mailto:]     On Behalf Of    Carl
Reed
Sent:    Mon,
21 Nov 2011 11:38 AM
To:    Darrell
O'Donnell; Trott, Gregory
Cc:    Elysa
Jones;     ;    
Subject:    Re:
[emergency] Question regarding
use of WGS84 reference system
in CAP standard
[SEC=UNCLASSIFIED]

Darrell
-

I
respectfully both agree and
disagree. Years ago a few of
us in the TC argued for CAP
being able to support
coordinate reference systems
other than WGS84 2d. At that
time, we made little
headway.

I work
standards in many venues.
Even the IETF community has
recognized the need to allow
alternative CRSs than just
WGS84. This is why, for
example, the location
extension to DHCP provides
for alternative CRSs to be
used.

There
is no issue with WGS84 being
the default CRS for a CAP
message. My suggestion was
to allow for the ability to
express other CRS’s than
WGS84. I was told that this
would add complexity and
that many systems that would
create or ingest a CAP
message would not
“understand” any other CRS
than WGS84. This assumption
I disagree with. Allowing
alternative CRS definitions
in the CAP specification
does not add complexity,
increases flexibility,
allows for national profiles
that adhere to national
mandates as to which geoid
to use, protects for the
future, as well as other
advantages. And, most
geotechnologies can deal
with CRS transforms – other
than perhaps some of the
very limited geo
capabilities in social media
location APIs – such as from
Twitter.

A
couple of years ago, the EM
TC agreed that at some point
CAP 2.0 would be developed.
The 2.0 version of CAP would
be enhanced to support the
new OASIS GML Simple
Features profile that is now
used in EDXL. An interesting
aspect of such a migration
is that GML provides for a
simple mechanism for
expressing one or more
coordinate references
systems.

I
agree that we do not want
one-off profiles for each
case in which national law
or other best practice
requires the use of a CRS
other than WGS-84. We in the
OGC community have
encountered this issue in
India, China, South Africa,
and a few other countries.
We have actually had to
allow the Chinese to modify
our standards to use China’s
mandated national CRS in
schema examples in order for
them to become Chinese
national standards.

So, as
you point out, there may be
an alternative solution in
Australia but this does not
solve the broader global
issue of CAP and the use of
a CRS other than WGS-84.

Regards

Carl
Reed, PhD
CTO
Open
Geospatial Consortium

Making
location count!
From:

Darrell
O'Donnell
Sent:

Monday,
November 21, 2011 6:39
AM
To:

Trott,
Gregory
Cc:

Elysa
Jones    ;        ;    
Subject:

Re:
[emergency] Question
regarding use of WGS84
reference system in
CAP standard
[SEC=UNCLASSIFIED]

Greg
et al.

I
will throw out a
cautionary note about
changing anything without
making it an explicit
different from CAP
addition. Though there is
value in supporting a
different coordinate
system, most groups have
agreed that CAP is strong
because it uses a single,
unambiguous, and widely
used coordinate system.
The broad use of WGS84 has
really opened up
geospatial capabilities
ranging from web mapping,
GPS, through to CAP.

The
GIS and survey-world will
argue differently and they
have valid reasons – they
need to be hyper-accurate.

For
alerting purposes we need
to focus on using a widely
known position format and
the minor inaccuracies
here are not worth
breaking this concept.
Many groups have argued
for better positioning and
different datums, but the
CAP community has
consistently looked at its
mission and realized that
WGS84 meets the needs of
the broad community. In
the case of GDA84, this
would be consistent with
guidance issued in
Australia, specifically by
the Intergovernmental
Committee on Surveying and
Mapping (ICSM). Here's a
link ( http://www.icsm.gov.au/gda/wgs84fact.pdf )
to an ICSM guidance site
that uses the phrase  for
most practical purposes
GDA94 and WGS84
coordinates can be
considered the same and no
transformation is
required.  There is a
caveat to that statement
in the document, that
basically states that if
you need to be
hyper-accurate, GDA94
needs to be explicitly
considered (see document
for full detail). I will
point out that for the
purposes of alerting, this
kind of accuracy is
meaningless. Alerting
doesn't operate at that
level of accuracy.

I am
happy to see that the ICSM
has made this kind of
guidance. As Australia is
leading an effort to
tailor CAP to their needs,
they are correctly asking
questions about the
WGS84/GDA94 difference.
From the ICSM I see a
strong argument in  living
with  WGS84. Adding a new
coordinate system to CAP
will cause widespread
angst and complexity in
the CAP alerting world –
I'd hate to see Australia
have to ask each vendor to
tailor their system to
support GDA94, as the
costs are not worth the
extra accuracy. Though the
issue looks so small at
the XML level we need to
be very careful about
going in this direction –
it is a slippery slope.

For
the GDA94 purists (I've
been there - I get it!), I
will throw out the
following idea. Keeping
pure on the CAP side and
allowing for the CAP-AU
profile to augment would
potentially be good. A
<parameter> or
<geocode>
valueName/value pair could
be used to support the use
of GDA94 IN ADDITION to
the normative WGS84
values. That will allow
the geo/survey savvy folk
to use the GDA94 values
without breaking the
systems that need WGS84.
Here is an example of the
CAP Canadian Profile    ( http://www.cap–cp.ca/ )
approach that uses a
point.
<parameter>
<valueName>layer:CAPAN:eventLocation:point</valueName>
<value>60.52459336850855,-117.66350189992689</value>
</parameter>

The
CAP-AU could make a
similar reference (I'll
make one up here):
<parameter>
<valueName>layer:CAP-AU:GDA94polygon</valueName>
<value>65.05568945905345,-122.5853768999256
63.76525349370743,-115.99358002492735
60.61097108402268,-113.62053314992798
57.542073550110594,-114.58733002492772
58.335165816909,-121.3549081499259  65.05568945905345,-122.5853768999256</value>
</parameter>

Hope
this helps.

Cheers,

--