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: Proposed agenda items for our next TM TC meeting 3-15-14

Here is a followup to the TEC agenda item I sent out earlier for our next EM-TC meeting.

Darrell made the following comment to the lasted version of the last_known_location field of the EM-TEC Client Registry Exchange specification. I include his comment below to aid in the discussion of this issue at our upcoming meeting:

"A text-based representation of a lat/long coordinate pair is not a geospatial coordinate. The norm would be to force a WKT (well-known text) or better, an OGC point-based geometry, that is not human driven. It could be typed in (unlikely), grabbed from a click on a map, or geocoded from an address. The key is that is specifically a geospatial geometry, not a human-typed in text value.

For more clarity, consider a user typing in coordinates. I have created dozens of systems that allowed this and every one has been massively problematic. User's can get coordinates in so many ways that without the rigour of a real geometry the data become worse than useless. Consider the following representations of a point that are all, in theory, the same point:
  • 77.5, -145.25
  • -145.25, 77.5 (invert long, lat as x, y)
  • 77d 30m N, 145m 15m W
  • 77 30', 145 15'
  • 77.5 00s, 145.25 00s (this is a common navigation format)
I can go on with many other examples and these are all valid - once you add the unintentional errors it gets really ugly.



Let's discuss this and any further thoughts on this element at the meeting.

Tony Mancuso

On Mon, Mar 17, 2014 at 11:42 AM, Anthony Mancuso <amancuso@google.com> wrote:
I have the following items I'd like to propose for discussion at our next EM-TC meeting:

Item 1. Approval of TEC Client Registry Exchange v 1.0 specification: last_known_address element:

The current EM-TEC Client Registry Exchange spec already supports the ability for automated tools to be able to input the last known location of a client in WGS84 coordinates. To make this clearer, updated the language of the last_known_location field, as follows (changed to the original text in bold):

last_known_location (Unicode string, optional):
A free-form description of the last known location of the person, which can be expressed as geographical coordinates. To specify geographic coordinates in this field, give the latitude in decimal degrees (positive for north), then a comma, then the longitude in decimal degrees (positive for east) . If this field is present, the text field of this note (the next field listed below) should describe HOW the person's location was determined .

text (Unicode string, required):
Free-form text description of the person's current condition, situation and location details, where they were last seen, corrections to other information, and so on. In entry forms, a multi-line text box is appropriate for this field. 

Item 2. Discussion of the following issues on the JIRA CAP 1.3/2.0 Issues List (listed under the EDXL CAP project -- we borrowed the CAP AU project, so these have "CAP-AU" as the abbreviated title).

Note that we ask all members to send written comments on this issue to the list to emergency@lists.oasis-open.org (you can reply response to this email). These comments will be copied to JIRA, which will collect all comments prior to a final vote on an issue by the TC.  


Tony Mancuso

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