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


Help: OASIS Mailing Lists Help | MarkMail Help

emergency message

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

Gary – noted on the signed message issue – it would have to happen at the originator level. I am betting Carl was considering the issuer and server to be one and the same, which I would agree with for the purposes of this discussion. Certainly the issuer and server don't need to be the same, but Carl's point is that it is quite easy to share out both WGS84 and coordinates in another CRS.

Your email raises a very good discussion point though – the burden is on the issuer.

Carl's point applies to the system that is issuing the alert, especially where digital signing is involved. To me it makes sense since most systems that use non-WGS84 coordinate systems nowadays can handle WGS84 as it has become a leveller. So, adding "hey this is my local CRS" parameter value still makes sense here.  

It's a good approach – I am betting if a system can handle an arbitrary CRS, it can handle WGS84 as well. The converse is not true from what I have seen in the wild.

At the CAP v1.2 level I can see adding a GML-compliant valueName/value that allows extension to the play. 

Here's a question though - on the future side (CAP v2+) when we allow for CRS data to be shared (that's good) will we require everyone to also share out a WGS84 common coordinate as well? To me, any part of CAP that isn't common becomes very dangerous. I can picture an alert that uses a new local state-plane coordinate system being totally useless to a receiving system that only understands WGS84.



From: Gary Ham <gham@grandpaham.com>
Date: Mon, 21 Nov 2011 14:02:43 -0500
To: Carl Reed <creed@opengeospatial.org>
Cc: Pete O'Dell <pete.odell@swanisland.net>, "Leinenweber, Lewis" <Lewis.Leinenweber@sesolutions.com>, Darrell O'Donnell <darrell.odonnell@continuumloop.com>, "Trott, Gregory" <Gregory.Trott@ag.gov.au>, Elysa Jones <elysajones@yahoo.com>, <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]

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

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.)
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
Sent: Monday, November 21, 2011 12:50 PM
To: Carl Reed; Darrell O'Donnell; Trott, Gregory
Cc: 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]
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.
From: emergency@lists.oasis-open.org [mailto:emergency@lists.oasis-open.org] On Behalf Of Carl Reed
Sent: Mon, 21 Nov 2011 11:38 AM
To: Darrell O'Donnell; Trott, Gregory
Cc: 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]
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.
Carl Reed, PhD
Open Geospatial Consortium
Making location count!
Sent: Monday, November 21, 2011 6:39 AM
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  (www.cap–cp.ca) approach that uses a point.
The CAP-AU could make a similar reference (I'll make one up here):
<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>
Hope this helps.
Darrell O'Donnell, P.Eng.
President/Principal Consultant
Continuum Loop Inc.
From: "Trott, Gregory" <Gregory.Trott@ag.gov.au>
Date: Mon, 21 Nov 2011 16:49:13 +1100
To: "emergency-cap-profiles@lists.oasis-open.org" <emergency-cap-profiles@lists.oasis-open.org>, "emergency@lists.oasis-open.org" <emergency@lists.oasis-open.org>
Subject: [emergency] Question regarding use of WGS84 reference system in CAP standard [SEC=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

If you have received this transmission in error please
notify us immediately by return e-mail and delete all
copies. If this e-mail or any attachments have been sent
to you in error, that error does not constitute waiver
of any confidentiality, privilege or copyright in respect
of information in the e-mail or attachments.

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