[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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
Cc: Pete O'Dell ; Leinenweber, Lewis ; Darrell O'Donnell ; Trott,
Gregory ; Elysa Jones ; emergency-cap-profiles@lists.oasis-open.org
; emergency@lists.oasis-open.org
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, From:
emergency@lists.oasis-open.org [mailto:emergency@lists.oasis-open.org] On
Behalf Of Gary Ham 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. 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 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: emergency@lists.oasis-open.org [mailto:emergency@lists.oasis-open.org] On Behalf Of Leinenweber,
Lewis 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: emergency@lists.oasis-open.org [mailto:emergency@lists.oasis-open.org] On Behalf Of Carl Reed 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 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, -- Darrell
O'Donnell, P.Eng. President/Principal
Consultant Continuum
Loop Inc. +1.613.866.8904 From: "Trott,
Gregory" <Gregory.Trott@ag.gov.au> UNCLASSIFIED Elysa Jones asked me to forward this email to the EM-TC and CAP
PROFILES SC to seek your views on how OASIS should handle an issue that has
arisen in the development of the Australian CAP Profile document with regard to
the WGS84 coordinate system. The Normative Reference list in the OASIS CAPv1.2 standard includes
the WGS84 as the datum source for geographic coordinates to be populated in CAP
messages. The use of WGS84 is no longer appropriate for the Australian
environment because the Geocentric Datum of Australia 1994 (GDA94) is now the
approved geographical coordinate system used in Australia. The GDA is a part of
the global coordinate reference frame and is directly compatible with the Global
Navigation Satellite Systems (GNSS), which is the generic term used to describe
the US Global Positioning System (GPS). Detailed information about
GDA94 can be obtained from Geoscience Australia at: http://www.ga.gov.au/earth-monitoring/geodesy/geodetic-datums/GDA.html The question we need your response to is: How should the different
geocentric datums be managed within the Australian CAP Profile document?
Two options that I feel might be appropriate methods to manage these
different datums in the Australian CAP Profile are: Option 1 – insert GDA94 into the Normative Reference list in the
CAP-AU Profile document to replace the existing WGS84 reference. - If any situation arose where a non-Australian CAP message was
received that provided geo location coordinates from a geo standard that is
different to the GDA94 (eg using the WGS84 or some other standard) then the
organisation in Australia who received the CAP message would not likely detect a
problem with the coordinates caused by use of different datums, until they had
to act on the coordinates and accurately find where the hazard was located
(perhaps to focus a satellite on the problem area or direct a rescue / recovery
team to the hazard location). - A Note should be added to the AREA element to highlight there is a
different datum system used in Australia and explain the potential for location
errors not to be detected by recipients in Australia. Option 2 - Retain WGS84 as a normative reference in the CAP-AU
Profile, and add the GDA94 as an additional Normative Reference plus add a note
into the AREA element to highlight there is a difference in Australia and
explain what is actually used in Australia. Can you please forward any comments or observations for consideration
to the EM-TC and Profiles SC email lists. Greg Trott CAP-AU Project Manager Australian Government Attorney-General's Department
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]