LoST: Location-to-Service Translation Protocol

LoST is "a protocol for mapping a service identifier and location information compatible with PIDF-LO to one or more service URL." It is designed by IETF-ECRIT working group to determine the location-appropriate Public Safety Answering Point (PSAP) for emergency services.

This demonstration introduces the extensions to LoST, enabling the protocol to support an array of services. The LoST extension draft details the different type of queries defined in the extension and the service classification draft outlines the services supported.

Developers can utilize the LoST protocol to develop Location Based Services by deploying a LoST client and a server.

A LoST server is deployed on http://lost.cs.columbia.edu:8080/Lost/ajaxServlet

The server is connected to a MySQL database containing services for Dublin and Manhattan. Each listing in the database consists of the Business name, url, latitude, longitude, address and phone number. Developers can query the server to get a list of services near the client. The server currently supports geodetic-2d and civic location profile along with the geodetic-civic location profile. The Geodetic-civic profile has not been standardized yet and has been implemented on a purely experimental basis

To query the server a developer needs to send an HTTP Post request to the server according to the format defined in the LoST extension draft. For the demonstration a sample web based LoST Client has been created, running on http://lost.cs.columbia.edu:8080/Lost The web based client will run on a browser supporting JavaScript. If viewed on an iPhone/iPod Touch, the client utilizes the mapping application to show the location of a business on the map.

The N type query finds the N nearest instances of a particular service. The content type for all types should be application/lost+xml

A Sample Query using the geodetic-2d profile:

<?xml version="1.0" encoding="UTF-8"?>

<findService xmlns="urn:ietf:params:xml:ns:lost1"

xmlns:p2="http://www.opengis.net/gml"

serviceBoundary="value" recursive="true" limit ="1">

<p2:Point id="point1" srsName="urn:ogc:def:crs:EPSG::4326">

<p2:pos>40.7128 -74.0092</p2:pos>

</p2:Point>

</location>

<service>urn:service:food.pizza</service>

</findService>

Response:

<?xml version="1.0" encoding="UTF-8"?>

<findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1"

xmlns:p2="http://www.opengis.net/gml">

<displayName xml:lang="en">Portobello Pizzeria Restaurant</displayName>

<service>urn:service:food.pizza</service>

<uri>http://www.google.com/local?source=uds&q=pizza&sll=40.714836,-74.011071&latlng=40714836,-74011071,13603040377665527046&near=40.714836,-74.011071

</uri>

<p2:Point id="point1" srsName="urn:ogc:def:crs:EPSG:4326">

<p2:pos>40.714836 -74.011071</p2:pos>

</p2:Point>

</serviceLocation>

</mapping>

</findServiceResponse>

The X Type query finds all requested services within a radius X.

A sample query using the civic profile:

<?xml version="1.0" encoding="UTF-8"?>

<findService xmlns="urn:ietf:params:xml:ns:lost1"

xmlns:p2="http://www.opengis.net/gml"

serviceBoundary="value" recursive="true" limit="1">

<A6>240 West, 104 Street</A6>

</civicAddress>

</location>

<service>urn:service:food.pizza</service>

</findService>

The XN Type query finds N instances of the requested services with a radius X. A sample query using geodetic-civic profile:

<?xml version="1.0" encoding="UTF-8"?>

<findService xmlns="urn:ietf:params:xml:ns:lost1"

xmlns:p2="http://www.opengis.net/gml"

serviceBoundary="value" recursive="true" limit="10">

<p2:Circle srsName="urn:ogc:def:crs:EPSG::4326">

<p2:pos>40.7128 -74.0092</p2:pos>

<p2:radius uom="urn:ogc:def:uom:EPSG::9001">3</p2:radius>

</p2:Circle>

</location>

<service>urn:service:retail.movies</service>

</findService>

For any queries regarding the LoST Client or Server please contact Andrea G. Forte or Milind Nimesh.

Department of Computer Science, Columbia University

When a query is sent to the server using Geodetic-2d or Civic profile the server responds using only the profile in which the query was sent. This can be a limiting factor in situations where the client has only geodetic information regarding the user but expects a response in civic or vice-versa. To address this limitation we implemented a profile called ?geodetic-civic? in which query could be either Civic or Geodetic-2d. The reply from the server, however will contain both Civic and Geodetic-2d based location information. By using this profile developers can simply send the coordinates of the user or business and get civic information or vice-versa, avoiding unnecessary geocoding on the client side.