Re: person location WRT position

A few emails ago I promised to provide clarification on the use of the terms 
"location" viz "position". Turns out that after reviewing the use of these 
terms in ISO, the OGC, and the IETF there appears to be consistency!

ISO 19112
    location: identifiable geographic place

ISO 19133
    position: data type that describes a point or geometry potentially 
occupied by an object or person

The only real difference here is that position is defined specifically as a 
data type (or a representation), while location is "place".  This means that 
the two terms are often used interchangeably, very similarly to the 
dichotomy between "resource" and "representation" when speaking of ROA.

The only distinction may be that "position" is restricted here to geometry 
(a point is a geometry, so the choice in the definition between the two is 
unneeded). So "the White House" is a location, but its position would have 
to be expressed as a geometry.

ISO 19133 uses this distinction to expand the concept of "coordinate 
transformation" (which works on positions) to the concept of "location 
transformation" which includes stuff like geo-coding which transforms named 
places like "1600 Pennsylvania Avenue" into positions (so they can be 
mapped); and inverse geo-coding going from points on a map to addresses or 
place names.

Raw tracking is position based (the phone's GPS sends coordinates, i.e. 
positions, in) but services (like navigation) do a lot of location 
transformations -- for example, putting addresses on map displays, or to 
answer question like "where am I?" which usually require a more human 
understandable expression than a lat-long. .

Various IETF documents use the following: location information describes a 
physical position in the world that may correspond to the past, present, or 
future location of a person, event, or device.

Almost identical. And all of the OGC location service standards use the same 
definitions.

Hope this helps.

Regards

Carl


----- Original Message ----- 
From: "C H" <craighubleyca@yahoo.com>
To: "Mandana Sotoodeh" <mandanas@ece.ubc.ca>; <paola.dimaio@gmail.com>
Cc: "public-xg-eiif" <public-xg-eiif@w3.org>
Sent: Wednesday, September 10, 2008 1:29 PM
Subject: Re: person location


>
>
> I think this contact and location information is much more dynamic and it 
> is very common to have to record complex instructions or complex paths 
> through spacetime to be sure that someone can rendezvous with someone else 
> in motion.  We can't assume that everyone everywhere has a satellite phone 
> but nor can we assume that someone being moved by someone else doesn't 
> ever need to be found en route (say for the delivery of some medicines not 
> at the evacuation point that they nonetheless need before they get to the 
> final destination).  "Bucket brigade" style transport where people or 
> goods often move from one vehicle to another also requires very close 
> coordination, but is extremely efficient in its use especially of special 
> purpose vehicles or drivers who know certain terrain well.  So I think a 
> deeper examination of how movement and contact between moving persons or 
> goods is handled is required, with "details" and "status" needing depth.
>
> --- On Tue, 9/9/08, paola.dimaio@gmail.com <paola.dimaio@gmail.com> wrote:
>> > - removed Population because it was originally there
>> to show the beneficiary
>> > of the services, now the two main agents in the model
>> are Organization and
>> > Person. If you think Population provides extra
>> information, I'll add it on.
>> >
>> > - Person has a location and consequently its subtypes
>
> There's some value to having an abstraction to represent collectives or 
> groups that are receiving services, but is "population" the right word?  I 
> doubt it.  In some cases there may be a client_group or beneficiary_group 
> designated to receive aid, if the word "population" is absolutely standard 
> to mean small sub-groups, then fine use it, but I'd seek a more specific 
> term.  I expect the term "population" to be a number of people living in a 
> specific place, not a rich descriptor of a number of demographics and 
> etc..
>
>> > - contactDetails is still a separate concept, common
>> between Person and
>> > Organizations, because organizations might have
>> general
>> > contact information which is not linked to a Person or
>> a Service.
>
> Of course it must be kept separate, but "details" may be a poor word 
> internationally (not used in the US or Canadian English as in UK English). 
> And there are different types of contact but of course those can be 
> "detailed" as emergency_contact, UK_daytime_contact, fax_number, etc.. 
> Frankly I'd rather see a very rich descriptor there containing a 
> contact_protocol or contact_strategy or how_to_contact (could be a long 
> list of strategies like "if it's daytime hours in the UK try reaching my 
> secretary at 044... but if you know I'm in Kuala Lumpur... satellite phone 
> number of my usual driver..." and perhaps at different security levels and 
> constantly updated for close colleagues while strangers get only generic 
> static published contact data.  A non-textual version of the 
> how_to_contact instructions might eventually have to become standard, like 
> a list of steps some of which can be automatically processed on a cell 
> phone processor.
>
> Perhaps a first step could be to differentiate published_contact_details 
> and private_contact_details, the latter containing any such rich 
> instructions... ?
>
>> > - added time-stamp and Status to Location (indicating
>> whether the location
>> > is valid, out of date, etc.),
>
> The system won't know this and generally won't be informed of anything 
> except perhaps a verification at odd intervals that the location is valid 
> *for now*.  So "status" might be a rich descriptor containing timeout and 
> verification data ("Dr. Smith found Dr. Jones at this location but Jones 
> indicated that he would be leaving it at noon for location X...") but in 
> general this is only valuable if it points to a set of future locations 
> (road to airport, airport to another airport, airport to hospital, etc.).
>
> So rather than time-stamping only the current location and having a messy 
> "status", perhaps we must think of location itself as being a spatial 
> location tied to a set of time spans, a data structure that looks like:
>
> - location now
> - location as of next known departure from location now / departure time
> - location as of next known departure from that location / departure time
> - location at which the individual will be located for forseeable future
>
> It's easy to see how this could fully and correctly describe, say, a 
> person in the midst of a medical evacuation.  Requiring only one update 
> for the structure, rather than an update to location every time they are 
> moved...
>
>
>
>
>
>
>
>

Received on Thursday, 11 September 2008 19:05:50 UTC