Subject: [Ecrit] LoST Extensions draft

From: "Andrea G. Forte" <[email-masked]>
Date: Wed, 19 Mar 2008 12:44:21 -0400

Dear all,

I just wanted to let you know that I have just submitted a new draft for 
your consideration.
Looking forward to your feedback.

Filename:	 draft-forte-ecrit-lost-extensions
Revision:	 00
Title:		 Location-to-Service Translation Protocol (LoST) Extensions
Creation_date:	 2008-03-19
WG ID:		 Independent Submission
Number_of_pages: 11

Abstract:
An important class of location-based services answer the question
"What instances of this service are closest to me?"  Examples include
finding restaurants, gas stations, stores, automated teller machines,
wireless access points (hot spots) or parking spaces.  Currently, the
Location-to-Service Translation (LoST) protocol only supports mapping
locations to a single service based on service regions.  This
document describes an extension that allows queries "N nearest" and
"within distance X".

URL: https://datatracker.ietf.org/drafts/draft-forte-ecrit-lost-extensions/

-Andrea

-- 

http://www.cs.columbia.edu/~andreaf/ 
<http://www.cs.columbia.edu/%7Eandreaf/>

_______________________________________________
Ecrit mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ecrit

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 19 Mar 2008 14:26:56 -0400

I should add that we don't expect this to become part of ECRIT  
charter, but since there isn't really another obvious home for this,  
we chose this WG for now. The goal of the draft is to illustrate that  
it is relatively straightforward to extend LoST to handle other types  
of services. Some of these may well even be useful for emergency  
coordination ("what are all hospitals in a 50 mile radius?").

Henning

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 19 Mar 2008 16:47:46 -0500

Having only scanned the doc (I know - bad dog!) - but it is short, I 
have a few simple questions - what exactly determines which hospital 
is closest?

For example, there could be one 8.4 miles away via a freeway, another 
7.8 miles away - but the path only has surface streets between me and 
that hospital, and another  5.1 miles away, but there is a river 
directly between me and the hospital - with a river crossing 5 miles 
away (making that 3rd hospital over 9 miles away).

If I have a 'limit' of 1, then the problem above is compounded by 
time of travel to get there being different than what's closest 'as 
the crow flies'...

Is this a function of a protocol, or of an application server that 
does the calculation, given the nearly exact location of all relevant 
points of interest (and knowing my location)?

I'm also curious how far out (i.e., how big) you can take the liberty 
(i.e., redefinition) of "area of uncertainty" to indicate an 
area?  Is this proportional to the size of the target?  I find it 
kinda hard to believe you have indicate a target as a specific point 
(indicating the center of a circle here) with a a radius of 2 miles 
or 50 miles or 500 miles -- where this radius was normally (i.e., 
previously) defined as the "area of uncertainty", in other words, the 
potential error in location measurement.

Further, doesn't this fairly radically change the XML of the PIDF-LO, 
and how the locations of each point of interest (in this case several 
hospitals are identified to the requester) are indicated to that requester?

Fundamentally, I think these URIs need to be returned either with or 
after the locations of the "points of interest" (POI) are returned to 
the requester.  It may do little good to get a URI to a Japanese 
restaurant because you are jonesing for some Sushi if you don't know 
where that restaurant is located - which could lead to your choice 
among the several returns (within the 'limit' element).  Sometimes 
you may want to know exactly where these restaurants are 
(geographically) to make a choice which URI to contact.  I think will 
necessitate returning a "PIDF-LO w/ associated URI" for each POI, in 
your LoST reply.

At least, this is what I would want from whatever service provided me 
this information.

Phase II - is not returning the nearest POIs to your location, but 
the nearest POIs to another location.  For example, I might know 
where there are several Japanese restaurants, but don't know just how 
many.  I'd like to enter (or give) a location and then ask "give me 
the nearest 25 Japanese restaurants to this <X> location, to then 
choice which among them, within a certain part of a city, I want to 
choose from.

Just a few thoughts

James

---

From: "Andrea G. Forte" <[email-masked]>
Date: Wed, 19 Mar 2008 18:25:16 -0400

Please read comments inline.

James M. Polk wrote:
> If I have a 'limit' of 1, then the problem above is compounded by time 
> of travel to get there being different than what's closest 'as the 
> crow flies'...
>
Yes, as you point out and as we mention in Section 6 of the draft, 
straight-line distance is not always the best metric. Because of 
obstacles, types of roads and other reasons, route (and travel time) 
rather than distance might be a better metric. This, however is not 
directly related to LoST as a protocol, but rather to how the server 
computes "closest". In reality this computation could be performed also 
on the client for "within distance X" queries and for "N nearest" 
queries when all the possible results are less than N.
The reason why we do not explicitly address this problem is because this 
is not really protocol related. You could imagine each company deploying 
such service using their own location-estimation techniques on their 
servers/clients.

> (i.e., redefinition) of "area of uncertainty" to indicate an area?  Is 
> this proportional to the size of the target?  I find it kinda hard to 
> believe you have indicate a target as a specific point (indicating the 
> center of a circle here) with a a radius of 2 miles or 50 miles or 500 
> miles -- where this radius was normally (i.e., previously) defined as 
> the "area of uncertainty", in other words, the potential error in 
> location measurement.
I am not sure if I understand what you mean here. However, I think that 
for POIs the area of uncertainty is useless. This depends on how the 
database containing these POIs has been populated. If you look at google 
maps, the position of POIs is very accurate.

> among the several returns (within the 'limit' element).  Sometimes you 
> may want to know exactly where these restaurants are (geographically) 
> to make a choice which URI to contact.  I think will necessitate 
> returning a "PIDF-LO w/ associated URI" for each POI, in your LoST reply.
>
Again, I am not sure I follow. In our draft the server returns the 
geodetic coordinates of each point of interest. So the client would know 
exactly where each POI is located.

-Andrea

>
> Phase II - is not returning the nearest POIs to your location, but the 
> nearest POIs to another location.  For example, I might know where 
> there are several Japanese restaurants, but don't know just how many.  
> I'd like to enter (or give) a location and then ask "give me the 
> nearest 25 Japanese restaurants to this <X> location, to then choice 
> which among them, within a certain part of a city, I want to choose from.
>
> Just a few thoughts
>
> James
>
>> > URL: 
>> https://datatracker.ietf.org/drafts/draft-forte-ecrit-lost-extensions/
>> >
>> > -Andrea
>> >
>> > --
>> >

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 19 Mar 2008 20:46:52 -0400

Just to amplify what Andrea is saying a bit...

On Mar 19, 2008, at 6:25 PM, Andrea G. Forte wrote:

>
> James M. Polk wrote:
>> Having only scanned the doc (I know - bad dog!) - but it is short,  
>> I have a few simple questions - what exactly determines which  
>> hospital is closest?
>>
>> does the calculation, given the nearly exact location of all  
>> relevant points of interest (and knowing my location)?
> computes "closest". In reality this computation could be performed  
> also on the client for "within distance X" queries and for "N  
> nearest" queries when all the possible results are less than N.
> The reason why we do not explicitly address this problem is because  
> this is not really protocol related. You could imagine each company  
> deploying such service using their own location-estimation  
> techniques on their servers/clients.

In my view, this is typically a client function. For example, your  
standard-issue Garmin/TomTom device (or Google Maps) can do this  
fairly easily already. Conveying all my travel preferences (walk vs.  
bike vs. train vs. car vs. helicopter, with numerous variations of  
fastest vs. cheapest vs. closest) would seem rather onerous. Plus, it  
would reveal more about myself to the location service than seems  
necessary.

We were trying to keep this relatively simple; there are plenty of  
extensions one can think of, such as "give me all ZAGAT-rated  
restaurants that have a fish special tonight, take Discover cards, are  
non-smoking, have a table for two near a window and are near a movie  
theatre that plays a romantic comedy". For that level of  
sophistication, we have the GloServ project (http://www1.cs.columbia.edu/~knarig/gloserv/Overview.html 
).

>
>
>>
>> I'm also curious how far out (i.e., how big) you can take the  
>> liberty (i.e., redefinition) of "area of uncertainty" to indicate  
>> an area?  Is this proportional to the size of the target?  I find  
>> it kinda hard to believe you have indicate a target as a specific  
>> point (indicating the center of a circle here) with a a radius of 2  
>> miles or 50 miles or 500 miles -- where this radius was normally  
>> (i.e., previously) defined as the "area of uncertainty", in other  
>> words, the potential error in location measurement.
> I am not sure if I understand what you mean here. However, I think  
> that for POIs the area of uncertainty is useless. This depends on  
> how the database containing these POIs has been populated. If you  
> look at google maps, the position of POIs is very accurate.

The meaning is essentially the same: "I'm somewhere in this region;  
please tell me about the services". We currently make no  
representation as to the probability distribution in either case.

>> where there are several Japanese restaurants, but don't know just  
>> how many.  I'd like to enter (or give) a location and then ask  
>> "give me the nearest 25 Japanese restaurants to this <X> location,  
>> to then choice which among them, within a certain part of a city, I  
>> want to choose from.
>>

The same protocol would work; just substitute another location or  
shape. There's nothing in the protocol that restricts queries to the  
current location.

Henning

---

From: Robins George <[email-masked]>
Date: Thu, 20 Mar 2008 18:43:24 -0700 (PDT)

how do we find the instances of a service in the  location B from the
location A ?
is it possible ?
and how how do we find a list/combination of instances of a service in a
location A ?
(for example I need to find the instances  of a restaurant and juice shop)

robins

-- 
View this message in context: http://www.nabble.com/LoST-Extensions-draft-tp16159750p16176346.html
Sent from the IETF - Ecrit mailing list archive at Nabble.com.

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 20 Mar 2008 22:04:57 -0400

> how do we find the instances of a service in the  location B from the

Yes. Nothing in LoST requires that the location provided is your  
current location.

> (for example I need to find the instances  of a restaurant and juice  

I'm not sure if you want to find restaurants that are also  
moonlighting as juice shops or a restaurant that is close to a juice  
shop. Assuming the latter, the current proposal would leave such  
operations to the client. Presumably, the list of juice shops and  
restaurants in the area of interest is reasonable in size, say, no  
more than a few hundred, so that client computation are feasible. As I  
mentioned before, our GloServ project does this explicitly, but it  
uses far heavier machinery, such as OWL.

Henning