Maps Geocoding and LocationBased Services 1 Maps Geocoding

Maps, Geocoding, and Location-Based Services 1

Maps, Geocoding, and Location-Based Services q USI NG L OC ATION-BASED SERVICES q CO NFIGURING THE EMULATOR TO TEST LOCAT ION-BASED SERVI CES q UP DATING LOCATIONS IN EMULATOR LOCATION PROVIDERS q SEL EC TING A LOCATION PROVIDER 2

Location-Based Services Introduction Location-Based Services or LBS allow software to obtain the phone's current location. This includes location obtained from the Global Positioning System (GPS) satellite constellation and Google’s cell-based location technology. 3

Location-Based Services Scenarios Location based services can be used in so many different scenarios. Such examples include : • Ride Sharing • Meet Anywhere • Social networking/Mobile Social networking • Buddy Finder/ Friend finder • location based Advertisement • location based business locator • tourism guides with text popup in different locations • Navigation • Traffic management • Car Parking guide • Mobile games • Emergency Services 4

Location-Based Services Limitations Geographic Limitation. Most of the current geographic search engines are only limited to USA and Canada. Some of them have a wider coverage including UK, Australia, Japan, Taiwan and few more countries. Other search engines which have not been mentioned here are (also often limited to a city or country or even to a specific language. Data Limitation. Existing location-based engines only cover commercially collected information of local businesses e. g. those mentioned in Yellow Pages. They do not cover World Wide Web although they might have link to those pages. Performance Limitation. An ideal geographic search and presentation has not been supported by some available search engines and they can not match interactive maps with textual geographic data properly. For example, map-based query refinement is not guaranteed. 5

Location-Based Services API Packages The Location-Based API includes two packages android. location & com. google. android. maps that provide an initial look at the support in the Android platform for building location-based services. Location-Based Service android. location com. google. android. map 6

Location-Based Services Location. Manager Class Location. Manager: It provides an API to determine location and access to the system location services which allow applications to obtain periodic updates of the device's geographical location. The application will be able to do three things: q Query for the list of all Location. Providers known to the Location. Manager for its last known location. q Register/unregister for periodic updates of current location from a Location. Provider (specified either by Criteria or name). q Register/unregister for a given Intent to be fired if the device comes within a given proximity (specified by radius in meters) of a given lat/long. 7

Location-Based Services Address, Criteria & Geocoder Class Address Class A class representing an Address, i. e, a set of Strings describing a location. Criteria Class A class indicating the application criteria for selecting a location provider. Providers maybe ordered according to accuracy, power usage, ability to report altitude, speed, and bearing, and monetary cost. Geocoder Class A class for handling geocoding and reverse geocoding. Geocoding is the process of transforming a street address or other description of a location into a (latitude, longitude) coordinate. Reverse geocoding is the process of transforming a (latitude, longitude) coordinate into a (partial) address. 8

UPDATING LOCATIONS IN EMULATOR LOCATION PROVIDERS We can use the Location Controls available from the DDMS perspective in Eclipse to push location changes directly into the emulator’s GPS Location Provider. Using the Manual tab we can specify particular latitude/longitude pairs. Alternatively, the KML and GPX tabs let us load KML (Keyhole Markup Language) and GPX (GPS Exchange Format) files, respectively. Once these are loaded we can jump to particular waypoints (locations) or play back each location sequentially. 9

UPDATING LOCATIONS IN EMULATOR LOCATION PROVIDERS 10

SELECTING A LOCATION PROVIDER Depending on the device, there may be several technologies that Android can use to determine the current location. Each technology, or Location Provider, will offer different capabilities, including differences in power consumption, monetary cost, accuracy, and the ability to determine altitude, speed, or heading information. To get an instance of a specific provider, call get. Provider, passing in the name: String provider. Name = Location. Manager. GPS_PROVIDER; Location. Provider gps. Provider; gps. Provider = location. Manager. get. Provider(provider. Name); This is generally useful only for determining the abilities of a particular provider. Most Location Manager methods require only a provider name to perform location-based services. 11

CHALLENGES IN DETERMINING USER LOCATION Obtaining user location from a mobile device can be complicated. There are several reasons why a location reading (regardless of the source) can contain errors and be inaccurate. Some sources of error in the user location include: Multitude of location sources GPS, Cell-ID, and Wi-Fi can each provide a clue to users location. Determining which to use and trust is a matter of trade-offs in accuracy, speed, and battery-efficiency. User movement Because the user location changes, you must account for movement by re-estimating user location every so often. Varying accuracy Location estimates coming from each location source are not consistent in their accuracy. A location obtained 10 seconds ago from one source might be more accurate than the newest location from another or same source. These problems can make it difficult to obtain a reliable user location reading. 12

REQUESTING LOCATION UPDATES This is how we can obtain user location on Android: Getting user location in Android works by means of callback. You indicate that you'd like to receive location updates from the Location. Manager ("Location Manager") by calling request. Location. Updates(), passing it a Location. Listener. Your Location. Listener must implement several callback methods that the Location Manager calls when the user location changes or when the status of the service changes. 13

For example, the following code shows how to define a Location. Listener and request location updates: // Acquire a reference to the system Location Manager Location. Manager location. Manager = (Location. Manager) this. get. System. Service(Context. LOCATION_SERVICE); // Define a listener that responds to location updates Location. Listener location. Listener = new Location. Listener() { public void on. Location. Changed(Location location) { // Called when a new location is found by the network location provider. make. Use. Of. New. Location(location); } public void on. Status. Changed(String provider, int status, Bundle extras) {} public void on. Provider. Enabled(String provider) {} public void on. Provider. Disabled(String provider) {} }; // Register the listener with the Location Manager to receive location updates location. Manager. request. Location. Updates(Location. Manager. NETWORK_PROVIDER, 0, 0, location. Listener); 14

REQUESTING USER PERMISSIONS In order to receive location updates from NETWORK_PROVIDER or GPS_PROVIDER, you must request user permission by declaring either the ACCESS_COARSE_LOCATION or ACCESS_FINE_LOCATION permission, respectively, in your Android manifest file. For example: <manifest. . . > <uses-permission android: name="android. permission. ACCESS_FINE_LOCATION" /> . . . </manifest> Without these permissions, your application will fail at runtime when requesting location updates. Note: If you are using both NETWORK_PROVIDER and GPS_PROVIDER, then you need to request only the. ACCESS_FINE_LOCATION permission, because it includes permission for both providers. (Permission for. ACCESS_COARSE_LOCATION includes permission only for NETWORK_PROVIDER. ) 15

Defining a Model for the Best Performance Location-based applications are now commonplace, but due to the less than optimal accuracy, user movement, the multitude of methods to obtain the location, and the desire to conserve battery, getting user location is complicated. To overcome the obstacles of obtaining a good user location while preserving battery power, you must define a consistent model that specifies how your application obtains the user location. This model includes when you start and stop listening for updates and when to use cached location data. 16

Defining a Model for the Best Performance This timeline representing the window in which an application listens for location updates. This model of a window—during which location updates are received—frames many of the decisions you need to make when adding location-based services to your application. 17

DECIDING WHEN TO START LISTENING FOR UPDATES You might want to start listening for location updates as soon as your application starts, or only after users activate a certain feature. Be aware that long windows of listening for location fixes can consume a lot of battery power, but short periods might not allow for sufficient accuracy. As demonstrated above, you can begin listening for updates by calling request. Location. Updates(): String location. Provider = Location. Manager. NETWORK_PROVIDER; // Or, use GPS location data: // String location. Provider = Location. Manager. GPS_PROVIDER; location. Manager. request. Location. Updates(location. Provider, 0, 0, location. Listener); 18

Getting a fast fix with the last known location The time it takes for your location listener to receive the first location fix is often too long for users wait. Until a more accurate location is provided to your location listener, you should utilize a cached location by calling get. Last. Known. Location(String): String location. Provider = Location. Manager. NETWORK_PROVIDER; // Or use Location. Manager. GPS_PROVIDER Location last. Known. Location = location. Manager. get. Last. Known. Location(location. Provider); 19

Deciding when to stop listening for updates The logic of deciding when new fixes are no longer necessary might range from very simple to very complex depending on your application. A short gap between when the location is acquired and when the location is used, improves the accuracy of the estimate. Always beware that listening for a long time consumes a lot of battery power, so as soon as you have the information you need, you should stop listening for updates by calling remove. Updates(Pending. Intent): // Remove the listener you previously added location. Manager. remove. Updates(location. Listener); 20