W3C home > Mailing lists > Public > public-geolocation@w3.org > December 2008

RE: BONDI use cases

From: Thomson, Martin <Martin.Thomson@andrew.com>
Date: Wed, 17 Dec 2008 16:45:37 -0600
Message-ID: <E51D5B15BFDEFD448F90BDD17D41CFF10539CC6B@AHQEX1.andrew.com>
To: Angel Machín <angel.machin@gmail.com>, "public-geolocation" <public-geolocation@w3.org>
It should be a criminal offence to post such inflammatory (i.e. interesting) emails so close to my vacation.



  This is a very bad requirement.  There is a natural tendency to look at particular location determination methods and try to make decisions based on this.  However, when you actually LOOK at the use cases this doesn’t address the core requirement.  What an application wants relate to the attributes: responsiveness, accuracy and other things like monetary costs.


The requirement here is not about methods: that’s a red herring.  The requirement is that a web application is able to do one of two things:


-          Select from a set of providers based on the set of attributes that each has.  That is, if you get a list of providers, each indicates its capabilities in terms of timeliness, accuracy and any other factors.  The application picks the one that suits it.

-          Specify a set of constraints (time, accuracy, cost, etc…) and get the best information that can be provided within that time.


One disadvantages of enumerating “Location Methods” is that new methods are introduced but not used because the web applications don’t know to select that method.  Web applications need to know, a priori, what each method represents to their use case.  That’s an unnecessary maintenance cost.


The rest of these requirements are fairly benign, even if there are some oddities (constraining longitude from -90 to +90 might work for the US and Europe, but we here in Australia would have a little difficulty).


Most can already be addressed by the geolocation API anyhow.  The only places geolocation falls short is in 480 and 490.





From: public-geolocation-request@w3.org [mailto:public-geolocation-request@w3.org] On Behalf Of Angel Machín
Sent: Thursday, 18 December 2008 1:40 AM
To: public-geolocation
Subject: Re: BONDI use cases


... and these are the requirements copied from the same document.




A Web Application SHOULD be able to manage and select the Location Providers available.



     A Web Application SHOULD be able to obtain a list of Location Providers available.


     For each Location Provider, the Location Method used by this Location Provider MUST be specified (as part of the returned information).


     A Web Application SHOULD be able to select a preferred Location Provider.


     At least one Location Method per Location Provider SHOULD be supported.


     Location Methods MAY include:

          - Angle of Arrival Method

          - Assisted Method

          - Cell-Id Method

          - Network Based Method

          - Terminal Based Method

          - Time Difference Method

          - Time of Arrival Method

          - Unassisted Method

          - WiFi Neighbourhood Method

          (See JSR 179 [10] and [11] for further details)





A Web Application MUST be able to obtain a one-shot location update.



     If the one-shot location update request fails, the Web Application SHOULD be returned the last known location retrieved by the Terminal or empty.


     The one-shot location update response object MUST include:

          - Latitude (-90 to +90 WGS84 degrees)

          - Longitude (-90 to +90 WGS84 degrees)

          - Altitude

          - Horizontal Accuracy (0 to 3.4028e+38 metres)

          - Vertical Accuracy

          - Timestamp (YYYY-MM-DDThh:mm:ssZ)

          - Heading

          - Velocity





A Web Application MUST be able to retrieve the last known location update information when the current location information cannot be determined on the Terminal.





A Web Application MUST be able to obtain periodic location updates.



     The Web Application MUST be able to implement and specify a location listener or an equivalent method of asynchronously receiving location updates.


     A Web Application MUST be able to stop periodic location updates. On completion, the associated location listener interface MUST NOT receive any further location updates.


     The Web Application MAY be able to specify a distance filter for the control of location notification intervals. The distance filter parameter states the minimum distance the user must move before an update event is generated and sent to the Web Application.





The Web Application SHOULD be able to programmatically specify a

timeout value for any location information request.



     If a location request timeout (on either the one-shot method [IFC-LOC-440] or the periodic location update method [IFC-LOC-460]) is reached, the request SHOULD return the last known location information.


     If a last known location update information is unavailable, the request SHOULD return an empty value or an exception.





The Web Application MAY be able to programmatically specify the desired

accuracy for any location information request.



     The Terminal MAY check a location as many times as needed to achieve the desired accuracy.


     The desired accuracy MAY be checked against the actual horizontal and vertical accuracy returned in a location response. (ref:   https://developer.apple.com/iphone/library/documentation/CoreLocation/Reference/CLLocationManager_Class/CLLocationManager/CLLocationManager.html)





A Web Application MUST be able to query the orientation of a Terminal.



     The orientation response object SHOULD include:

          - azimuth: the Terminal's horizontal compass bearing in relation to true north: 0 to 360 degrees.


     The orientation response object MAY include

          - pitch: the Terminal's angle in a vertical plane orthogonal to the ground: -90 to 90 degrees),

          - roll: the Terminal's rotation in degrees around its own longitudinal axis: -180 to 180 degrees)



This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
Received on Wednesday, 17 December 2008 22:46:23 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:50:53 UTC