[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [emergency-cap-profiles] RE: [emergency] Question regarding use of WGS84 reference system in CAP standard [SEC=UNCLASSIFIED]
P.S. on Wednesday, 11/23 CAP Profiles SC meeting…
We will also be discussing the form that the CAP-AU Profile URN-based name should take, such as “profile:EDXL-CAP1.2-AU:1.0”.
We are aware that Gary Ham and others have advocated standardizing this URN-based Profile format, so we again welcome everyone’s participation on our CAP Profiles SC call on 11/23 from 4:00-5:00 PM ET where this topic that may affect all other Profiles going forward will be discussed.
From: firstname.lastname@example.org [mailto:email@example.com] On Behalf Of Timm, Gary
To all commenters on the WGS84/GDA94 issue,
This is a great discussion; thank you everyone.
The members of the CAP Profiles SC would like to invite all of you to our next call to discuss this topic:
Wednesday, November 23, 4:00-5:00 PM ET.
Please see Kavi for call-in details.
The SC is on a fast track to vote on a CAP-AU Profile WD on the next Wednesday, November 30, so tomorrow 11/23 is THE day to discuss this important topic.
We hope to hear as many of you important OASIS visionaries on our call as possible – we truly need you on this one.
Gary Timm, CAP Profiles SC Scribe
Touchstone Consulting Group
1920 N Street NW, Suite 600
Washington, DC 20036
Mobile: (202) 465-6394
From: firstname.lastname@example.org [mailto:email@example.com] On Behalf Of Darrell O'Donnell
Don – By throwing in the unit-of-measure concept you bring up a critical point that makes me lean stronger towards forcing a single CRS (WGS84) and unit-of-measure.
Unit of Measure – Differences Make Mistakes
The aerospace industry has learned from harsh lessons that any kind of "required conversion" will inevitably fail. Examples of the Gimli Glider (fuel measured in pounds/litre instead of kilograms/litre) when gallons was expected), Mars Climate Orbiter (force calculated in Newtons, entered in pound-foot), Boeing's woes with imperial/metric subcontractors, and others prove this point.
That being said, I would not want to impose a variable unit-of-measure upon people. I can just picture someone, a lazy developer for example, writing code that rips through a message, determines that there is an issue at 3000 metres above sea level and not issuing an alert because his city is only at 900 metres above sea level. When one realizes the unit of measure was feet, the actual altitude is about 950 metres – now we have introduced a problem. The developer's mistake would be in not looking for unit of measure.
I guess I have a lot of heartache in forcing both the issuer and receivers to understand different coordinate systems. I also wonder what utility is added by allowing a different – as opposed to additional – CRS in here at all. The value of CAP is that it provides a simple system for exchanging of alerting systems. Adding any complexity that can be handled outside of CAP (see point below about coordinate conversion) doesn't add value in my opinion – it adds confusion and complexity.
To me the complexity of supporting multiple CRSes belongs at the issuer and receiver ends. If you really need it – do it. The tools are there and it isn't really that hard – but it's hard enough to stunt the growth of CAP, IMHO.
Easy for Vendors/Developers/Users
CAP is popular because it is dead simple. The concepts that it embodies are not simple, but the CAP data format is quite simple. Here's a basic policy approach that CAP supports: if you want to impose policy on particular things (e.g. Limit who can issue Severe Tornado alerts) you can do so – but that isn't in the data. It is in the processing before or after the issuance of an alert.
The barrier to entry for issuing and receiving CAP alerts is quite low – it requires little geo-savvy, unlike projections.
If we add another layer of complexity we make things more difficult. Even the manual use case for CAP works with WGS84 - a user can receive an email with a WGS84 coordinate and quickly go to google or bing maps and type in the lat/long of a point and get a real approximation of where something is happening. They can't do that with any other CRS – not accurately. The geodetic systems will provide an approximation, and GDA94 will be darned close and arguably more precise than the map is accurate. Put in an UTM-based CRS and you're going to be off-planet immediately.
Now, let's take a developer who is really good at coding, but a neophyte with GIS – a neo-geo. I guarantee that at some point during their development they will transpose the y,x (were y=latitude, and x=longitude) coordinates – they think in regular cartesian x,y. They will fix it quickly and be mildly humbled. Now throw in the requirement to understand the well-known CRS (assume an EPSG supported and widely used CRS) that an Alert is in and we have just added a whole new layer of complexity for little value and I am betting, a lot more heartache and potential error – especially with y,x and x,y ordering differences in many CRSes. Now, let's assume that the CRS is either obscure or new and the receiving system doesn't have anything for it – no EPSG code to use a library. I suppose we could pass the raw parameters (if received) into a projection library like Proj4 (or other tools) but this is yet another layer of complexity. Add in the group that just received a new EPSG and sends out their message without the parameters and we don’t have any way to figure out the coordinates.
On a development front, the reality that I see is that the n=1 case is trivial – but n>1 is rarely trivial. If there is no choice in CRS/UOM then a developer can proceed with little risk. If there is a choice, things get more complex, meaning more development time, more testing time (massive increase in test cases), and inevitably more errors. As a development lead I want that simplicity – our developers can focus their ability to solve complex problems on the things that warrant the domain knowledge to handle the complexity.
NOTE: I am using the phrase complex here a lot. I have been doing coordinate conversion, transformation, and projection for years – it isn't crazy hard, but it is an extra step that I don't see worthwhile here. It isn't really magic or rocket-science, but you had better know what you're doing when you start doing this stuff. My rule for well engineered software is that you have to prove to me the need for complexity before we go ahead.
Carl's discussion about the availability of tools – server and libraries – that can handle the projection and transformation of data is key to me. I see it being needed on the incoming (issuer end) and outgoing (receiving end) to allow integration of locale-specific CRS. On the wire, I like sticking with one single projection. The de facto standard worldwide right now is WGS84 – there is no CRS that compares for adoption level especially in the information exchange space. The fact that modern geodetic projections with a datum like GDA94 are, for the intents and purposes of CAP, pretty much the same (10cm difference horizontally with WGS84 and GDA84) means I could get away with using my locale's coordinates if they are geodetic, but I shouldn't. The more dangerous scenario that I see is the use of UTM and other variants that provide non-geodetic coordinates.
I'll throw in what may be considered a bit of a snarky comment here too - I don't mean it that way though. The folks that are pushing for the adoption of different CRS use are the ones that understand what they are. To me that means they are best suited to correctly convert their local CRS to WGS84 on issuing and receiving alerts. They get the concepts and they know how to do this – so let's apply that know–how to the issuing and receiving ends.
I think it would be a great idea to put forth some reference architecture/examples that shows how a system should implement CRS support. I work on the Canadian MASAS project and I am leading the architecture work there. I can see a CRS layer wrapping around our server where we can request our data in various CRS that are needed (there are plenty).
We can also recommend an approach where a CAP Profile can list the expected CRSes and how data should be shared out (using GML and the CRS of choice). Here is an area where OGC soars way above other groups – the references and guidance it produces have massively increased the use of geospatial technology and capabilities.
I recommend we keep the de facto standard WGS84 geodetic (EPSG:4326) on the wire. Do the transformation at the issuer and receiver end if needed.
Obligatory Quotation: Make everything as simple as possible, but not simpler. - Albert Einstein
Now – Back to the concept of simplicity and consistency - unit-of-measure – feet and kilometres in the same spec???? I defer to others for that one or at a minimum, I'll leave that for another day. :–)
PS – yes, I know this is like sticking my head into a hornet's nest. I've done it before – it hurts for a bit but it thickens the skin.
Darrell O'Donnell, P.Eng.
Continuum Loop Inc.
From: "McGarry, Donald P." <firstname.lastname@example.org>
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:
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.
The MITRE Corp.
From: Carl Reed <email@example.com>
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.
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 ; firstname.lastname@example.org ; email@example.com
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:
<![if !supportLists]>1. <![endif]>Allow multiple Coordinate systems / units of measure to be sent out over the wire
<![if !supportLists]>2. <![endif]>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.
From:firstname.lastname@example.org [mailto:email@example.com] 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.)
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: firstname.lastname@example.org [mailto:email@example.com] 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.
SE Solutions, Inc.
From: firstname.lastname@example.org [mailto:email@example.com] On Behalf Of Carl Reed
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!
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.
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.
Continuum Loop Inc.
From: "Trott, Gregory" <Gregory.Trott@ag.gov.au>
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.
CAP-AU Project Manager
Australian Government Attorney-General's Department
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]