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-cap-profiles] Proposed solution - WGS84 versus CRS issues for the CAP-AU Profile [SEC=UNCLASSIFIED]

> 1) Inclusion of a GDA94 reference in the Normative References section of the CAP-AU Profile
> document (the WGS 84 reference is retained as well further down the list)
> 2) A statement in the header row of the <area> element explaining the GDA94 issue
> 3) An example for a circle location in the <area> section that includes GDA94 coordinates in
> a <parameter> sub-element (as recommended by Darrell O'Donnell) and corresponding WGS84
> coordinates using the CAP <circle> sub-element (the coordinates are deliberately the same at
> present - I am still trying to locate a tool that can convert the WGS 84 coordinates that I
> extracted from Google Maps (-35.123,150.727) into GDA94)

The coordinates in WGS84 and GDA94 are the same for that level of precision.  There is only a divergence when you get below 1 metre.  Which leads to the question, is sub-metre accuracy necessary for public alerting?  Since GDA94 was introduced to be more compatible with WGS84 than AGD was, can it not be considered, for the purposes of public alerting, to be equivalent?

I would recommend dropping #3 from the above list as I think this will set a precedent where we could end up with a proliferation of ad hoc geospatial values, all with the intent of replacing those specified by the standard, leading to interoperability problems.  This precedent would also mean that if someone didn't like the values in <severity> they could define their own parameter that would instead override it, and so on.  There is an acknowledged need for other CRS's and CAP 2.0 will be addressing it.  I don't think we should start creating divergent methods of expressing geospatial information that could be incompatible with 2.0 and result in interoperability issues between 1.2 systems.

Would expanding on #1 and #2 as noted above to draw attention to the differences and provide a statement that in this profile they are considered to be equivalent or a substitution thereof be sufficient?

Jacob Westfall <jake@jpw.biz>

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