[OASIS Issue Tracker] (EMERGENCY-7) Client Registry Exchange: last_known_location format

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ https://tools.oasis-open.org/issues/browse/EMERGENCY-7?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=36972#comment-36972 ] 

Tony Mancuso commented on EMERGENCY-7:
--------------------------------------

Darrell O'Donnell: I strongly recommend breaking the lat/long values out into their own column. Embedding them means that the data are of little utility to a GIS as the data need to be processed and results will be very inconsistent. This is a reasonable thing to ask a developer. I find the suggest as is to be quite odd myself – I haven’t typed in a lat/long in ages – software (hey – like Google Maps) makes getting a lat/long pair from a map or address trivial. The text can still talk about how the LKP was determined, and describe the sighting and exact area.

KaPing: I don't see anything wrong technically with putting latitude/longitude coordinates in their own column.  For the sake of process simplicity, though, I would rather make that change in a subsequent version of the EDXL-TEC standard.  If we first establish an equivalence between PFIF 1.4 and EDXL-TEC 1.0, then we are right out of the starting gate with a standard that has many existing interoperable implementations, rather than creating a slightly different standard that has no existing implementations yet.  My thinking is that being able to say that there are working implementations puts the standard in a good spot, from which we can make revisions and then motivate everybody to migrate.

From Darrell: 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.

Ka-Ping: PFIF specifies a particular format (decimal degrees, latitude first) which should address most of the machine processing issues I think?  I realize this is not as solid as say the kml spec but pretty reliable -- it's a very common unambiguous format and is exactly the one that works in the Google Maps search box as well.

Darrell: The issue here is that this approach is quite inconsistent with the EM-TC's work to date. Introducing a third format (CAP has an outdated format) is not going to sit well with the EM-TC



> Client Registry Exchange: last_known_location format
> ----------------------------------------------------
>
>                 Key: EMERGENCY-7
>                 URL: https://tools.oasis-open.org/issues/browse/EMERGENCY-7
>             Project: OASIS Emergency Management TC
>          Issue Type: Improvement
>          Components: TEC
>            Reporter: Tony Mancuso
>            Assignee: Elysa Jones
>              Labels: Client-Registry-Exchange
>
> This issue tracks the discussion of whether to modify the PFIF last_know_location element currently included in the TEC Client Registry Exchange specification, v. 1.0:
> 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.



--
This message was sent by Atlassian JIRA
(v6.1.1#6155)