Preview only show first 10 pages with watermark. For full document please download

Progetto Simple Mobile Services: Realizzazione Di

   EMBED

Share

Transcript

Università degli studi di Roma “Tor Vergata” Facoltà di Ingegneria Corso di Laurea Triennale in Ingegneria Informatica Tesi di Laurea Progetto Simple Mobile Services: realizzazione di un proxy verso servizi di mappe e localizzazione geografica Relatore: Ing. Stefano D. Salsano Laureando: Alessio Bianchi Anno accademico 2007-2008 Sessione di aprile Licensed under Creative Commons License “Attribution – Share alike” 2.5 Alessio Bianchi Typesetted in LATEX 2ε . Written in gedit with the gedit LATEX plugin. A mio padre Sommario Il progetto europeo Simple Mobile Services si pone come piattaforma per la creazione e la fornitura di servizi in mobilità, pensati per essere facilmente fruibili sui dispositivi mobili. Uno dei servizi offerti è il Navigator, che permette di visualizzare una mappa navigabile e su cui l’utente può visualizzare i risultati di ricerche di un indirizzo o di un’attività commerciale, oppure un percorso tra due indirizzi. La logica di applicazione che fornisce tali dati al Navigator è costituita da un’applicazione lato server apposita. Questa si appoggia a diversi servizi di mappe disponibili sul Web, e risponde alle richieste inviate dal Navigator con i dati richiesti secondo un opportuno formato. L’oggetto di questo lavoro di tesi è appunto la progettazione e l’implementazione di tale applicazione, e la sua integrazione con il Navigator. Abstract The European project Simple Mobile Services is a platform for authoring and deployment of mobile services, which are thought to be easily used on mobile devices. One of the offered services is the Navigator, which allows users to view a navigable map on which they can see the results of various kinds of queries, such as address searches, business searches or routes between two addresses. The business logic providing such data to the Navigator consists of a server-side application. This application queries data from various, freely available map services, and responses to the Navigator’s requests according to an appropriate format. The goal of this thesis work is the design and the implementation of such application, and its integration within the Navigator. Contents 1 Introduction to Simple Mobile Services 1.1 Mobile services as of today . . . . . . . . . . . . . . . . . 1.1.1 Mobile devices limits . . . . . . . . . . . . . . . . 1.1.2 User interaction . . . . . . . . . . . . . . . . . . . 1.1.3 Costs . . . . . . . . . . . . . . . . . . . . . . . . 1.1.4 Developing mobile services . . . . . . . . . . . . . 1.2 Web services through SMS: simplicity and completeness 1.3 The MOVE application and its components . . . . . . . 1.4 The MOVE’s outdoor navigator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1 1 2 2 2 3 4 6 2 Map services 2.1 Common concepts . . . 2.1.1 Query types . . . 2.1.2 Geocoding . . . . 2.1.3 Maptiles . . . . . 2.2 Google Maps . . . . . . 2.2.1 Address search . 2.2.2 Business search . 2.2.3 Route calculation 2.3 Yahoo Maps . . . . . . . 2.3.1 Address search . 2.4 MSN Live Local . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 11 11 11 12 12 12 13 14 14 14 15 . . . . . . . . . 16 16 17 17 18 20 22 25 25 32 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 SMS Navigator Proxy 3.1 Previous solution outline . . . . . . . . . . . . . . 3.2 New solution outline . . . . . . . . . . . . . . . . 3.3 Interface constraints . . . . . . . . . . . . . . . . 3.3.1 Request format . . . . . . . . . . . . . . . 3.3.2 A revision to the original response format 3.3.3 Response format . . . . . . . . . . . . . . 3.4 Requirements analysis . . . . . . . . . . . . . . . 3.4.1 Use case description . . . . . . . . . . . . 3.4.2 Class diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5 . . . . . . . . . . . 36 36 37 38 43 43 44 46 46 47 47 4 Future developments and conclusions 4.1 Future developments . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 48 49 A Map services output examples A.1 Google Maps . . . . . . . . . A.1.1 Address search . . . . A.1.2 Business search . . . . A.1.3 Route calculation . . . A.2 Yahoo Maps . . . . . . . . . . A.2.1 Address search . . . . 3.6 Implementation . . . . . . . . . . . . . . . . . . . . . . 3.5.1 Dynamic content generation: PHP . . . . . . . 3.5.2 Main code . . . . . . . . . . . . . . . . . . . . . 3.5.3 The Google Maps map provider . . . . . . . . . 3.5.4 The Yahoo Maps map provider . . . . . . . . . 3.5.5 The MSN Live Local map provider . . . . . . . 3.5.6 The Automatic map provider . . . . . . . . . . Integration in the MOVE client . . . . . . . . . . . . . 3.6.1 navigator/smsnavigator/MapTileManager.java 3.6.2 navigator/smsnavigator/PrefsEditor.java . . . . 3.6.3 navigator/smsnavigator/SearchMenu.java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 51 51 52 53 54 54 B SMS Navigator Proxy code reference B.1 MapProvider Class Reference . . . . . . . . . . B.2 GoogleMaps Class Reference . . . . . . . . . . . B.3 YahooMaps Class Reference . . . . . . . . . . . B.4 MSNLiveLocal Class Reference . . . . . . . . . B.5 Automatic Class Reference . . . . . . . . . . . . B.6 AddressResultset Class Reference . . . . . . . . B.7 BusinessResultset Class Reference . . . . . . . . B.8 RouteResultset Class Reference . . . . . . . . . B.9 MapProviderFactory Class Reference . . . . . . B.10 MapProviderException Class Reference . . . . . B.11 NonExistentAddressException Class Reference B.12 NetworkProblemException Class Reference . . B.13 LocalIOException Class Reference . . . . . . . B.14 ServiceUnavailable Class Reference . . . . . . . B.15 SMSNavigatorProxyException Class Reference B.16 Function Reference . . . . . . . . . . . . . . . . B.17 Configuration Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 56 58 61 62 64 66 67 67 68 69 69 69 69 69 69 69 72 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 Chapter 1 Introduction to Simple Mobile Services In this chapter a general introduction to the mobile service world and the Simple Mobile Services platform is presented. Section 1.1 analyzes the peculiarities and design strategies of mobile services and the characteristics of mobile devices. Section 1.2 report the characteristics of web services provided within the Simple Mobile Services platform. Section 1.3 is about the client-side application of Simple Mobile Services, called MOVE. Section 1.4 analyzes the main functionalities of the Navigator, a component of the MOVE client. 1.1 Mobile services as of today To date, mobile services have substantially failed to match the explosive growth of the World Wide Web [1]. The reasons of this scarce success are to be searched for among several aspects of the mobile business. We may distinguish them in several main categories, as explained below. 1.1.1 Mobile devices limits Most mobile devices provide only basic input devices, mainly consisting of a numerical pad and arrow keys. Some of the most bleeding-edge models may offer more advanced input means, such as touch screens or even full-sized QWERTY keyboards, but ergonomics is still lower if compared to standard PC peripherals. Screen are necessarily smaller than PCs’, and frequently with a lower color depth. The bigger they are, the more power they require and, consequently, the shorter is the power autonomy of the device. CPU power and memory is also considerably inferior than PCs’, as their costs and power saving problems pose a crucial issue. Finally, Internet connections carried via typical protocols such ash GPRS are often characterized with high latencies and low speed. Things are getting better 1.1 Mobile services as of today 2 since the introduction of the HSDPA protocol, which allows downlink speeds with order of magnitude of the megabit per second (Mbit/s). 1.1.2 User interaction Besides ergonomic problems, another set of issues regarding user interaction must be held into account, as they are emphasized by the mobile device’s limits. Traditional PC’s input peripherals are designed to allow data input as comfortably as possible for the user. Conversely, the main design goal for mobile devices input devices is primarily compactness. Consequently, the amount of data a user is willing to input on a mobile device is typically far more little than on a PC. Mobile services requesting the same amount of input data on a PC and on a mobile device are then destined to be used sporadically. An effective way to reduce user input could be making the service as more ‘context-aware’ as possible by considering the user’s position, the time of day, the social context, etc. Similar considerations hold for output as well. A mobile service providing so much data to exceed the screen, forcing the user to ‘scroll’ frequently needs rethinking the logic to present data to the user, in order to find a more succinct and effective way. Today’s services are most often lacking interoperability among one another, and this affects several common usage scenarios. For example, consider a user who is planning a weekend abroad to watch a music event. When he books a flight, he may also be interested in finding a convenient accommodation, as well as buying the tickets for the music event. This typical scenario would benefit a lot if the flight company, the hotels and the event organization committee made their web services mutually inter-operable. 1.1.3 Costs Unlike most traditional Internet access technologies, like DSL, mobile access to Internet is often expensive and subject to pay-per-use pricing structure. When WAP was the only protocol on the market, users were charged on the time they spent online. With the introduction of packet oriented mobile data services such as GPRS and HSDPA, users were then charged on the effective amount of data they exchanged1 . This problem is becoming less and less important over time, as most providers offer fairly cheap promotions and discounts. 1.1.4 Developing mobile services Designing mobile services mainly follows one of these strategies: Mobile browsers This approach is about producing services optimized for being used on mobile browsers. Examples include ‘Google Mobile’, ‘Google Maps 1 In Italy, as of today, the average fee (not considering providers’ special offers) is about 0,4 eurocents per kilobyte. 1.2 Web services through SMS: simplicity and completeness (a) Wikipedia on Sony Ericsson P990i. [17] 3 (b) Amazon on iPhone. [18] Figure 1.1: Mobile browsers displaying PC designed web sites. Mobile’, ‘Yahoo Mobile’, ‘eBay Mobile’ and others (see fig. 1.2). This way, theoretically, services would be accessible to every mobile device with a browser. However, most mobile web browsers still lack complete standards-adherence and interaction capabilities such as Javascript support. Moreover, an intrinsic limitation of this solution is that the actual web has been designed for desktop PC usage; a mobile web cannot be only an adaptation of the fixed one, but should exploit new features which mobile devices can provide, like context awareness. Dedicated applications This approach, on the contrary, is about developing dedicated applications to be installed on mobile devices, in order to overcome the limitations of the above solution. Examples include ‘Yahoo Go’ and the location-based applications available in recent high end phones (e.g. Nokia N95). A disadvantage of this solution is that there will be, eventually, a large number of different applications poorly inter-operating. Another drawback is that the entire service creation process will be proprietary, leaving few possibilities for users to create their own services. 1.2 Web services through SMS: simplicity and completeness The Simple Mobile Services [3] approach follows the ‘dedicated application’ solution outlined in section 1.1.4, but it attempts to overcome the drawback of that solution by proposing a common framework to integrate heterogeneous services and an open architecture to encourage both expert developers and end-users to author mobile services. To sum up, the fundamental idea in the SMS platform is that mobile 1.3 The MOVE application and its components 4 Figure 1.2: Google Maps Mobile. Example of route calculation running on the Opera Mini browser emulator. services should not be simple to create and set up just for developers, but also simple to find, to use and to trust for users. 1.3 The MOVE application and its components The MOVE (Mobile Open & Very Easy) application (see figure 1.3) is the main application running on SMS-enabled mobile devices. MOVE is a “service browser” that allows users to access the required services among the available ones. Services are implemented by using several components, which may reside in the local MOVE application or may be located in a remote server and communicate through a lightweight middleware. The main page of MOVE can be easily customized by the user to show his favourite services, and it can also change dynamically according to the user context information (e.g. user location, user current activity). As of today, the available services are: MEM messaging and handling A MEM (Mobile Electronic Memo) [2] is an electronic note containing structured data. It can contains information related to a location, a person, a service, the status of an ongoing activity, etc. Users can get MEMs from the environment, store them, share them with other users and using them as input for other components (like the Navigator). MEMs are thought to reduce the amount of data to be asked the user to input, as outlined in section 1.1.2. 1.3 The MOVE application and its components Figure 1.3: Screenshots from the MOVE application. 5 1.4 The MOVE’s outdoor navigator 6 Indoor navigator The indoor navigator allows the user to get walking directions in indoor environments such as airports, malls, hospitals, campuses, etc. It can notify and drive the users toward points of interests, which are arranged as MEMs. The user position may be obtained either by an indoor localization system based on Zigbee or by asking the user to enter it. Outdoor navigator The outdoor navigator is meant to be similar to most car GPS navigator systems. It can show street maps, find addresses and businesses and show the route towards destinations. The user position may be obtained by connecting to an external GPS receiver via Bluetooth. The data used by this component is provided by a proxy, which provides an abstraction layer for a generic maps/navigation service, and makes it possible to use different service providers, such as Google Maps, Yahoo Maps or MSN Live Local. Find my friends This component provides information about the location of friends and it is fully integrated with the outdoor and indoor maps and navigation components. The location of friends can then be used to get direction to reach them. 1.4 The MOVE’s outdoor navigator As outlined in section 1.3 on page 4, one of the components of the MOVE application is the outdoor navigator. It is meant to mimic all the functions of a traditional car GPS navigator appliance, while providing a certain degree of integration with other SMS services. Thanks to a Bluetooth GPS receiver it can acquire location data from the GPS positioning system. Map services can also be consulted if a GPS receiver is not available: in this case, street addresses or even geographic coordinates may be entered. Once opened, the navigator shows a map centered to the last viewed location. The user can pan the map by using the appropriate scrolling device on his mobile device, typically arrow keys or a joystick. All the main functions of the navigator are accessed through a menu. The user can control the zoom level of the map by the menu entries ‘Zoom in’ and ‘Zoom out’. There is an entry for each type of supported map search: ‘Find a place’ The user wants to search for a street address and to center the map onto it. The street address is requested, and a list of matching addresses (possibly more than one) is presented. The user then chooses one option and a pin corresponding to the address point is shown on the map. ‘Find a business’ The user wants to search for businesses of a certain category near a location. As location, a street address, the current map position or the GPS position may be used, as chosen by the user. A list of matching businesses is presented and, for each of them, a pin is shown on the map. The map is centered and zoomed in order to fit all pins on the screen area. 1.4 The MOVE’s outdoor navigator 7 Figure 1.4: Displaying restaurant MEMs on the Navigator’s map. ‘Find a route’ The user wants to obtain driving instructions to go to one location to another. Both of the locations may be independently chosen by entering a street address, using the current map position or the GPS position2 . The driving path is then showed on the map by creating a pin for each waypoint. Below the map, the waypoint direction is shown. The user may move back and forth among waypoints using the keys * and #3 . Each search is saved into a local cache accessible through the entry ‘Last searches’. Searches can also be saved into a bookmark list, accessible through ‘Bookmark menu’; the current map center can also be added to bookmarks. The user’s current location obtained from the GPS receiver can be set as center of the map: this is accomplished by the ‘Show current position on map’ menu entry. The ‘Preferences’ entry gives access to a panel where the user may set several preferences for the navigator: the most important are the URL of the server running SMSNavigatorProxy, the map provider to use and the language to view search results into. 2 Obviously, using map position for both the address is not allowed, as well as using the GPS coordinates. 3 These keys are valid for mobile phones. 1.4 The MOVE’s outdoor navigator Figure 1.5: Navigator’s map area while dowloading maptiles. Figure 1.6: Address search example. 8 1.4 The MOVE’s outdoor navigator Figure 1.7: Business search example. 9 1.4 The MOVE’s outdoor navigator Figure 1.8: Route calculation example. 10 Chapter 2 Map services In this chapter, an outline of the three map services used in this thesis work is presented. For each map service, a “user-interaction” perspective is presented, followed by how to make this interaction suitable for automatic processing. A categorization is made according to the three types of queries implemented in the Navigator: address search, business search and route calculation. 2.1 2.1.1 Common concepts Query types The query types implemented in SMSNavigatorProxy are: Address search The user provides a street address and the system returns a pair of geographic coordinates. Business search The user provides a business category (i.e. pizzeria, cinema, etc.) and a street address, and the system returns a list of corresponding businesses nearby the given address. Route calculation The user provides two street address, and the system returns a car path from the first to the second address, composed of waypoints coordinates and driving directions. 2.1.2 Geocoding Each of the seen query types is based onto a fundamental operation, internally executed by the map service, called geocoding. It is a process which correlates a physical street address with a pair of geographic coordinates indicating latitude and longitude. As it will turn out clear soon, every query type consists of at least one geocoding operation. 2.2 Google Maps 2.1.3 12 Maptiles Other than textual data returned by map services (geographich coordinates, businesses list, etc.), a map is to be visualized on the Navigator. The map is composed by several portions, called maptiles, in form of raster digital images. Correspondance between geographic coordinates and maptile identification is done by the Navigator. SMSNavigatorProxy, thus, receives an identifier which is directly used to retrieve the maptile. 2.2 Google Maps Google Maps (http://maps.google.com/) [4] is a free map service provided by Google. It features an AJAX based [5] map that users can pan (by dragging the mouse) and zoom (by using the mouse wheel). It offers all of the three query types listed in section 2.1.1. 2.2.1 Address search Requests of this type take an address as input. The address is geocoded and the map is then centered on the yielded coordinates, and zoomed at a level that allows appropriate level of detail with respect to the level of detail of the address. So, if a user specifies a nation name as address, the zoom level is chosen low enough to wrap at least that nation in the map. Conversely, if an alley is requested, the chosen zoom level is very high. Users may enter addresses which are not precise enough to be geocoded1 . In this case, a list of narrower results is provided and the user must choose an option to view the address on the map. Great flexibility is offered when parsing addresses. For example, the following addresses are all accepted and succesfully geocoded: via via via via via del del del del del corso roma corso, 00186 corso, 00186 corso, 00186 corso, 00186 roma roma (lazio) roma (lazio) italia roma (RM) lazio italia This is a convenient feature, especially when using a mobile device. Indeed, it is highly desiderable to enter, by the limited keyboard at disposal, as few characters as possible, and Google Maps supports this by recognizing simple, unstructured address such as “via del corso roma”. Moreover, Google Maps is able to detect most typos in the addresses, and to suggest appropriate corrections (the “Did you mean” notice, also seen in web search engine). 1 An example is the Italian road “Via Casilina” which spans across multiple cities. 2.2 Google Maps 13 As documented in [6], geocoding can be performed by a simple HTTP request. The format of returned data can be chosen among xml, kml, csv, or json2 . The URL to use to perform a geocoding operation is: http://maps.google.com/maps/geo?hl=HL&q=ADDR&key=KEY&ie=UTF8&output=kml where: HL is the ISO language code requested for output (i.e. it, en, de, etc.) ADDR is the address to be geocoded KEY is the Google Maps API key, which can be obtained for free on http://code. google.com/apis/maps/signup.html If the address is ambiguous, all address matches are returned. If the address is non existent or otherwise invalid, a KML file containing code different than 200 is returned. For a complete description of the error codes, refer to [7]. For an example of the KML geocoding output of the address “via del politecnico, roma”, refer to code A.1.1. For more details about the implementation of this process, refer to section 3.5.3. 2.2.2 Business search Requests of this type take an address and a business category (in form of a string) as input. The address to look for businesses around is geocoded, and then businesses of the specified category not too far away from the coordinates are shown on the map. Unfortunately, no documentation is offered about doing queries of this kind by an HTTP request. However, by trial and error, it is possible to derive the following URL to use: http://maps.google.com/maps?f=l&hl=HL&q=CAT&near=ADDR&z=16&ie=UTF8& output=kml where CAT is the business category. If the category name is misspelled or otherwise invalid, or the address is ambiguous or non existent, a 0-bytes long KML file is returned. It is however possible to determine if there is ambiguity or invalidity of the address: this can be achieved by manually geocoding the address first. This routine, in fact, returns more helpful error messages. This way, if a 0 bytes long KML file is obtained, it is certain that the problem is with the category specified. For an example of the KML output for restaurant search near the address “via del tritone, roma”, refer to code A.1.2. 2 XML is the W3C’s eXtensible Markup Language, KML is an XML dialect used by Google Earth, CSV is Comma Separated Values, JSON is JavaScript Object Notation. 2.3 Yahoo Maps 2.2.3 14 Route calculation Requests of this type take two addresses as input, corresponding to the departure and arrival address. Both of these addresses are geocoded and it is determined whether a car route exists between them3 . If it exists, the directions to follow are returned, in form of geographic coordinates of waypoints. This case is also not documented, and again it is needed to resort to trials and errors to get a useful URL, which is: http://maps.google.com/maps?f=d&hl=HL&saddr=SRC&daddr=DST&ie=UTF8& output=kml where: SRC is the departure address DST is the arrival address If case of an error, a 0 bytes long KML file is returned. To determine which error situation applies, the source and destination addresses have to be geocoded manually and independently. If the first address is uniquely geocoded, the second address must be checked. If this one is uniquely geocoded as well, then there must not be possible to elaborate a car route between the two locations. Conversely, if one of the addresses is not uniquely geocoded, it is necessary to prompt the user to make the necessary corrections. For an example of the KML output corresponding to a route calculation from “via del corso, roma” to “via del tritone, roma”, refer to code A.1.3. 2.3 Yahoo Maps Yahoo Maps (http://maps.yahoo.com/) [8] is a free map service provided by Yahoo!. Similarly to Google Maps, it features an Adobe Flash based [9], draggable and zoomable map. The services offered are the same than Google Maps’, but the amount and detail level of data is slightly lower, at least for searches in the Italian territory. In contrast with Google Maps, only the address search service can be used by automatic processing tools. 2.3.1 Address search Although being the only service which results can be automatically parsed, its completeness and flexibility is as good as Google Maps’, and it is very well documented in [10]. The URL to use for making requests is: http://local.yahooapis.com/MapsService/V1/geocode?appid=APPID& location=ADDR where: 3 For example, an error is returned if you want to cross the Atlantic Ocean. . . 2.4 MSN Live Local 15 APPID is the Yahoo application ID, which can be obtained for free on http:// developer.yahoo.com/wsregapp/. This is an identifier similar to a Google API key. ADDR is the address to be geocoded. The parsing flexibility of addresses is comparable to Google’s, allowing unstructured addresses to be correctly recognized. The available output formats, which can be selected by adding the output variable to the above URL, are standard xml (default) and serialized php [11]. If the address is ambiguous or non existent, an XML document containing an error is returned. Moreover, error codes are also returned as standard HTTP response codes, as documented in [12]. For an example of the output of the address “via del politecnico, roma”, refer to code A.2.1. 2.4 MSN Live Local MSN Live Local (http://intl.local.live.com/) is a free map service provided by Microsoft. Unlike the other two map services previously seen, it only features business search. It is based on simple XHTML. The amount of listed businesses is sensibly lower than Google’s or Yahoo’s. Moreover, flexibility in parsing addresses is very low: for example, ‘Via del Corso’ in Rome must be inserted as “Via del Corso, 00186 Roma RM, Italy”. This address structure is inconveniently rigid, as all chunks of the address are mandatory and must be consistent. It is, thus, very uncomfortable to use this service, even on the PC! MSN Live Local offers no directly-parseable data format. The previous implementation of this service in SMSNavigatorProxy, which has been conserved nearly unaltered, consists in extracting raw data from the HTML code of the response page by using several regular expressions. For more details about the implementation, refer to sections 3.1 and 3.5.5. Chapter 3 SMS Navigator Proxy This chapter focuses on the design and implementation process of the new SMSNavigatorProxy, underlining changes with respect to the previous solution. The navigator does not query map services directly: instead, it exploits a serverside application called SMSNavigatorProxy, which isolates the SMS environment and provides a level of abstraction toward a generic map provider, as well as a unified syntax for requesting data to the proxy and interpreting responses. 3.1 Previous solution outline The previous solution is based on a PHP server-side application. The only available map provider is Google Maps. Requests toward it are made as HTTP requests using the GET method for sending data. The response is returned as XHTML code, containing the data to be extracted and, for the most part, XHTML code to present data as an interactive, AJAX based web application. Data is extracted from the response pages’ XHTML code using regular expressions. This approach is severely affected by the instability of the response page’s structure, as it may fail after a change in the way of presenting results data on the page. It has been experienced that a change in the page’s CSS style sheet1 required consequent adjustments to the regular expressions. Furthermore, when extending this application to interface with new map providers, very little code can be reused, as the adopted solution is specifically tailored for Google Maps. For these reasons, one of the main goal of this thesis work is to “stabilize” the Navigator’s data back-end, providing better service levels and easing future expansion to other map providers. 1 In detail, the change of class name of the XHTML entity corresponding to a result in the CSS. 3.2 New solution outline 3.2 17 New solution outline The new solution retains the original server-side orientation and it is written in PHP. Other than Google Maps, the Yahoo Maps and MSN Live Local map providers are implemented. The provider to be used can be chosen for each request. Requests toward map providers are still handled by HTTP requests using the GET method. The biggest difference with the previous solution relies in the format of responses. The new solution is based on the fact that if requests are made using an appropriate parameter, the data is returned as an XML document. These files can be easily and natively parsed by most programming languages, in order to extract single tokens. Such tokens are then assembled together and formatted following the syntax specified in section 3.3.3 and sent back to the MOVE client. This approach features a very high stability, as the XML document’s scheme is far less likely to change than the web page XHTML code. Supporting this aspect, it should be noticed that, in the case of Google Maps, such XML scheme is used as a data exchange format between Google Maps and Google Earth. Hence, this format is even less likely to be changed in the future, as both Google Maps and Google Earth would be affected. This particular XML schema is called KML. Yahoo Maps, whose implementation is completely new, also provides responses using a particular XML scheme, so the same considerations made above for Google Maps about stability apply here as well. As of writing, this format is not used by other Yahoo services, so it could be argued that it is more likely than KML to be modified in the future. However, it is still much more stable than XHTML code. MSN Live Local, on the contrary, does not offer responses in XML format. Consequently, the legacy approach of extracting data using regular expressions has been maintained nearly unaltered. It is easy to see that this service will be first to break in the near future due to data format changes. Finally, an ‘automatic’ map provided has been developed. Requests served by this provider are forwarded to the Google Maps provider; if an error is detected, the request is automatically and transparently forwarded to the Yahoo Maps or the MSN Live Local provider, depending on the requested search type. 3.3 Interface constraints In order to successfully communicate with the MOVE client, both the communication entities have to use a common protocol. Its implementation in the new SMSNavigatorProxy should use the ‘legacy’ protocol as closely as possible, in order to guarantee an easy migration to the new solution without too much effort to realign the protocol on the MOVE client. The format of requests and responses to implement follows. 3.3 Interface constraints Variable a mode hl address what saddr daddr gx-gy-gz yx-yy-yz mr provider Address search ? ? ? ? 18 Business search ? ? ? ? ? Route search ? ? ? Request map tile ? ? ? o o ? (1) ? (2) ? (3) o o Table 3.1: Type of requested service and GET variables to provide. If the provider is Automatic, the groups (1), (2) and (3) must be all passed. Otherwise, just pass the group corresponding to the provider in use. For the provider variable, ‘o’ means optional: the Automatic provider will be used. Address search Business search Route search Map tile Google Maps ? ? ? ? Yahoo Maps ? MSN Live Local ? ? ? Table 3.2: Services availability per map provider. 3.3.1 Request format Requests are done by calling a PHP script by retrieving the resource at the following URL: http://baseurl/SMSNavigatorProxy/smsnavigator.php?[GET_variables] baseurl depends on the web-server configuration2 . [GET_variables] is a set of pairs variable_name = variable_value. The meaning and accepted values of each recognized variable are reported below. The variables to use for each type of requested service are summarized in table 3.1. The a variable Type of request (search or map tile). 2 The baseurl value presently used on the production server is http://stud.netgroup. uniroma2.it/~bianchi 3.3 Interface constraints Accepted values search maptile 19 Meaning Perform a search (address, business, route) Request a map tile The mode variable Type of requested service (address search, business search, route calculation). Accepted values 1 2 3 Meaning Address search Business search Route search The hl variable The language to return results into. Accepted values ISO language codes (e.g. it, en, fr, de) The provider variable Map provider to use to serve requests. If this variable is not provided in the URL (it is ‘missing’, according to PHP terminology), the Automatic map provides is used. Note that not all types of requested service are implemented for each map provider. The allowed provider/mode combinations are summarized in table 3.2. Accepted values GoogleMaps YahooMaps MSNLiveLocal Automatic Meaning Use GoogleMaps; on error, fallback of requests to YahooMaps and MSNLiveLocal The address variable Address to search for (address search) or to find business around to (business search). Accepted values Text string (e.g. “via del tritone, roma”, “Via del Politecnico, 00133 Roma RM”, “fifth avenue, new york”) 3.3 Interface constraints 20 The saddr and daddr variables Respectively, the source and destination address of a route (route search). Accepted values Text string (e.g. “via del tritone, roma”, “Via del Politecnico, 00133 Roma RM”, “fifth avenue, new york”) The what variable Category of business. Accepted values Text string (e.g. cinema, restaurant) The gx, gy and gz variables Coordinates and zoom level in Google Maps’ coordinate system. Accepted values Integer values The yx, yy and yz variables Coordinates and zoom level in Yahoo Maps’ coordinate system. Accepted values Integer values The mr variable Coordinates and zoom level in MSN Live Local’s coordinate system. Accepted values Integer values 3.3.2 A revision to the original response format Although, as said before, it is advisable to retain the former communication protocol, it has been verified that some adjustments have to be done, as some data fields which were previously extracted from the XHTML code are not provided in the XML response. This is the case of polylines in Google Maps’ route calculations. A polyline is a string encoding an ordered list of geographic coordinates. An example polyline is available in code 3.1 Polylines are used in route calculations to depict the overall route from the departure address to the arrival one as a line on the map. The points encoded for this 3.3 Interface constraints 21 1 ogn~Fuq‘lAv@l@n@‘A??~@jJKJOn@DjAZz@ZPXx@r@~HDnBEzA??[b@Gz@PfAN\XHHA^{@AkAxH}AXU?? g@uBE] Code 3.1: Polyline encoding the route from ‘Via Tor Vergata, Roma’ to ‘Via del Politecnico, Roma’. discarded waypoints Figure 3.1: Vertexes composing a polyline. Vertexes corresponding to waypoints (marked as red) will be included in the response. Vertexes used only to split a curved path into segments (marked as black) will be discarded. purpose are the geographic coordinates of the segment’s vertexes composing the line. Special vertexes are the waypoints, having a corresponding direction (‘Turn right’, etc.). In some cases, a polyline contains many vertexes but the route has few waypoints: this is typically the case of roundabouts and, more in general, sharp turns. In these situations, most of the coordinate pairs decoded from the polyline would be simply discarded by the MOVE client. This situation is depicted in figure 3.1. The HTML code retrieved in the old solution used to contain the full polyline and which coordinate pairs corresponded to actual waypoints. This two pieces of data were sent to the MOVE client, which decoded the polyline and retained only the coordinate pairs of waypoints. However, in the XML response, things have changed (see code A.1.3). The polyline is no longer provided in the response and, to top it all, the waypoints coordinates are not highlighted. If one wanted to maintain the very same response format, he should calculate the polyline by encoding all of the coordinates, figure out which coordinates among others are waypoints and send these results back to the MOVE client. However, it is easy to see that polyline management this way is now just a useless complication of the protocol: the adopted approach is to send waypoints’ coordinates without any encoding. For more details about revised response format, refer to section 3.3.3. For the 3.3 Interface constraints 22 consequent modifications to the MOVE client, refer to section 3.6. 3.3.3 Response format Address search If the address is not ambiguous (e.g. a single result was returned by geocoding), the response has to conform with the following schema: 1 SEARCHRESULTS:
Code 3.2: Address search – schema. An example of address search (“via del tritone, roma”, using Google Maps) is the following: 1 SEARCHRESULTS:12.484105 41.902474 Via del Tritone, 00187 Roma, Roma (Lazio), Italy Code 3.3: Address search – example. On the contrary, if the address is ambiguous (e.g. multiple results were returned by geocoding), the response has to conform with the following schema (3.4): 1 2 3 4 SEARCHRESULTS:OPT OPT ... Code 3.4: Address search – ambiguous address schema. An example of address search with an ambiguous address (“via casilina”, using Google Maps) is the following: 1 2 3 4 5 6 7 8 9 10 11 SEARCHRESULTS:OPT OPT 12.683648 41.862152 Via Casilina, Roma, Roma (Lazio), Italy 13.982522 41.413610 Via Casilina, Italy 13.097946 41.733354 Via Casilina (Lazio), Italy 12.935453 41.772493 Via Casilina, 00038 Valmontone, Roma (Lazio), Italy 13.418448 41.588285 Via Casilina, 03027 Ripi, Frosinone (Lazio), Italy 13.702377 41.510913 Via Casilina, 03030 Castrocielo, Frosinone (Lazio), Italy -116.935158 32.749332 Via Casilina, El Cajon, CA 92019, USA 13.253108 41.686182 Via Casilina, 03013 Ferentino, Frosinone (Lazio), Italy 13.777970 41.489519 Via Casilina, 03030, Frosinone (Lazio), Italy 13.316331 41.658601 Via Casilina, 03011 Alatri, Frosinone (Lazio), Italy Code 3.5: Address search – ambiguous address example. Business search The address is first geocoded; if it is not ambiguous, the response has to conform with the following schema: 3.3 Interface constraints 1 2 3 4 23 SEARCHRESULTS: ... Code 3.6: Business search – schema. An example of business search (“pizzeria” near “via del tritone, roma”, using Google Maps) is the following: 1 SEARCHRESULTS:12.483128 41.903609 Via Della Mercede, 18, 00187 Roma (RM), Italy ( Ventiquattro Srl - 06 69200252) 2 12.482035 41.903237 Via Della Mercede, 45, 00187 Roma (RM), Italy (Appia Nuova 2003 S.R.L. - 06 6786015) 3 12.482394 41.900953 Via Dei Crociferi, 16, 00187 Roma (RM), Italy (Planet Pizza Haridy Saad Abd Elall - 06 8171786) 4 12.482394 41.900953 Via Dei Crociferi, 16, 00187 Roma (RM), Italy (Planet Pizza 06 6780871) 5 12.486099 41.902368 Via Del Traforo, 131, 00187 Roma (RM), Italy (Caso - 06 42823750) 6 12.486109 41.905203 Via Degli Artisti, 37, 00187 Roma (RM), Italy (Deldo S.r.l. 06 4884023) 7 12.480451 41.899976 Via Di Pietra, 85, 00186 Roma (RM), Italy (Suaf Srl - 06 6780973) 8 12.490040 41.904020 Via Barberini, 16, 00187 Roma (RM), Italy (Terrazza Barberini - 06 42014596) 9 12.480352 41.906304 Via Della Croce, 17, 00187 Roma (RM), Italy (Calvi Srl - 06 6791386) 10 12.478076 41.904383 Via Del Leoncino, 28, 00186 Roma (RM), Italy (Baldi - 06 6867757) Code 3.7: Business search – example. If the address is ambiguous, the list of address matches is returned according to schema 3.4. When the condition ‘no results’ or ‘address not ambiguous and category invalid’ (e.g. mispelled) is satisfied, the following schema is to be used: 1 SEARCHRESULTS: Code 3.8: No results schema. Route calculation If both the addresses are not ambiguous and there exists a car route between them, the response has to conform with the following schema: 1 2 3 4 5 SEARCHRESULTS:,,center ,,span ... Code 3.9: Route calculation – schema. 3.3 Interface constraints 24 The pairs , and , denote, respectively, the coordinates to center the map onto, and the the maximum distance between the center and the farthest waypoint. These values are used to draw the map on the MOVE client and to calculate a zoom level to contain all the waypoints. They are calculated by finding, in the set of latitude,longitude pairs of the response, the values min_lat, max_lat, min_lon, max_lon. Then: center_lat = min_lat + max_lat 2 min_lon + max_lon 2 span_lat = center_lat − min_lat center_lon = span_lon = center_lon − min_lon An example (from “via del corso, roma” to “via cavour, roma”) follows: 1 SEARCHRESULTS:12.488195,41.899955,center 2 0.008715,0.003515,span 3 12.479480 41.903200 Procedi in direzione sud da Via del Corso verso Via in Lucina (0,2 km) 4 12.480190 41.901540 Svolta a sinistra a Largo Chigi (87 m) 5 12.481190 41.901780 Prosegui su Via del Tritone (0,6 km) 6 12.488040 41.903470 Svolta a destra a Piazza Barberini (17 m) 7 12.488210 41.903380 Prosegui su Via delle 4 Fontane (0,5 km) 8 12.493110 41.900640 Prosegui su Via Agostino Depretis (84 m) 9 12.493900 41.900170 Svolta leggermente a sinistra a Piazza del Viminale (0,1 km) 10 12.494840 41.899670 Prosegui su Via Agostino Depretis (0,2 km) 11 12.496380 41.898810 Prosegui su Piazza dell’Esquilino (87 m) 12 12.496910 41.898150 Svolta a destra per rimanere su Piazza dell’Esquilino (28 m) 13 12.496680 41.897970 Prosegui su Via Cavour (0,2 km) 14 12.495070 41.896440 Arriva a: Via Cavour, Roma RM, Italia () If one of the two addresses is ambiguous, the following schema must be followed: 1 2 3 4 SEARCHRESULTS:OPT OPT ... Code 3.10: Route calculation – ambiguous address schema. is either OPTsaddr or OPTdaddr, depending on which of the two addresses is ambiguous. If both the addresses are ambiguous, OPTsaddr is used and partial matches for the source address are returned; the user should pick an option from the list of partial matches and a new request, with a non ambiguous source address, must be done. At this point, the destination address is still ambiguous, so the user should choose one option and make the final request, which will have non ambiguous addresses. This interaction sequence is highlighted in figure 3.5. 3.4 Requirements analysis 25 Map tile Map tiles must be returned in form of a PNG image enclosed in the following schema: 1 MAPTILE: Code 3.11: Map tile – output schema. where PNG_data is the actual image file. The image should be cached on the server in a directory specific for each map provider. Error management Errors must conform to the following schema: 1 ERROR: Code 3.12: Error – output schema. where describes the occurred error. 3.4 Requirements analysis This phase of the software development process consists in defining, as precisely as possible, what the software should do, by producing a complete description of the behavior of the system to be developed. Eliciting requirements has been done primarily by interviews with the authors of the Navigator and the previous Navigator proxy, and through a set of examples the response format should conform to. 3.4.1 Use case description A detailed description of use cases specified in the use case diagram (fig. 3.2) follows. Address search Actors MOVE client, map provider Preconditions A request with the variables a=search and mode=1 is received. Main flow It is checked whether the request contains the variables hl and address. A map provider object, according to the value of the provider value, is instantiated. The map provider object’s handler for address searches is invoked. The XML response is parsed and the coordinates and addresses are extracted. A response is assembled with such data, following the appropriate response format. Finally, the response is sent back to the MOVE client. Alternative flows 3.4 Requirements analysis 26 ud: SMSNavigatorProxy − Use case diagram SMSNavigatorProxy boundary Address search Business search Route calculation MOVE client Map provider Map tile retrieval Figure 3.2: SMSNavigatorProxy – Use case diagram. 3.4 Requirements analysis 27 The request does not contain one or both of the hl and address variables. An error is sent back to the MOVE client. The value of the variable provider does not correspond to any available provider, or there is an error during object instantiation An error is sent back to the MOVE client. The map provider does not support the requested service. back to the MOVE client. An error is sent An error during the request to the map provider occurs. If the provider is Automatic, fallback the request to Yahoo Maps or MSN Live Local. A sequence diagram depicting this interaction for an address search request is available in figure 3.3. If the provider is not Automatic, an error is sent back to the MOVE client. Business search Actors MOVE client, map provider Preconditions A request with the variables a=search and mode=2 is received. Main flow It is checked whether the request contains the variables hl, address and what. A map provider object, according to the value of the provider value, is instantiated. The map provider object’s handler for business searches is invoked. The XML response is parsed and the coordinates and addresses are extracted. A response is assembled with such data, following the appropriate response format. Finally, the response is sent back to the MOVE client. Alternative flows The request does not contain at least one of the hl, address and what variables. An error is sent back to the MOVE client. The value of the variable provider does not correspond to any available provider, or there is an error during object instantiation An error is sent back to the MOVE client. The map provider does not support the requested service. back to the MOVE client. An error is sent An error during the request to the map provider occurs. If the provider is Automatic, fallback the request to Yahoo Maps and MSN Live Local. A sequence diagram depicting this interaction for a business search request is available in figure 3.4 (recall service availability, as reported in table 3.2). If the provider is not Automatic, an error is sent back to the MOVE client. The address is ambiguous. client. Return a list of address choices to the MOVE The business category is invalid. MOVE client. Return an empty list of results to the 3.4 Requirements analysis 28 Route calculation Actors MOVE client, map provider Preconditions A request with the variables a=search and mode=3 is received. Main flow It is checked whether the request contains the variables hl, saddr and daddr. A map provider object, according to the value of the provider value, is instantiated. The map provider object’s handler for route calculations is invoked. The XML response is parsed and the coordinates and waypoints are extracted. A response is assembled with such data, following the appropriate response format. Finally, the response is sent back to the MOVE client. Alternative flows The request does not contain at least one of the hl, saddr and daddr variables. An error is sent back to the MOVE client. The value of the variable provider does not correspond to any available provider, or there is an error during object instantiation An error is sent back to the MOVE client. The map provider does not support the requested service. back to the MOVE client. An error is sent An error during the request to the map provider occurs. back to the MOVE client. An error is sent One of the addresses is ambiguous. Return which address is ambiguous and a list of address choices to the MOVE client. Sequence diagram of figure 3.5 summarizes the interaction between the MOVE client, SMSNavigatorProxy and the map provider in the case when both the addresses are ambiguous. Map tile retrieval Actors MOVE client, map provider Preconditions A request with the variable a=maptile and at least one of the variable groups gx-gy-gz, yx-yy-yz, mr (depending on the provider) is received. Main flow A map provider object, according to the value of the provider value, is instantiated. The map provider object’s handler for map tile retrieval is invoked. The image is saved into the local cache directory corresponding to the provider. A response is assembled with the image, following the appropriate response format. Finally, the response is sent back to the MOVE client. Alternative flows provider=GoogleMaps and the request does not contain at least one of the variables gx, gy or gz. An error is sent back to the MOVE client. provider=YahooMaps and the request does not contain at least one of the variables yx, yy or yz. An error is sent back to the MOVE client. 1) results for "via del corso, roma" 2) results for "via del corso, roma" GoogleMaps : 4) results for "via del corso, roma" 4) .address search: "via del corso, roma" 3) [exception] 3) .address search: "via del corso, roma" Automatic : 2) .address search: "via del corso, roma" SMSNavigatorProxy : 1) .address search: "via del corso, roma" MOVE client : sd: Address search − Automatic provider: fallback to YahooMaps Yahoo Maps : 3.4 Requirements analysis 29 Figure 3.3: SMSNavigatorProxy – Sequence diagram: Address search - Automatic provider, fallback to YahooMaps. 1) [results] 2) [results] 2) .business search: "pizzeria", "via del corso, roma" SMSNavigatorProxy : 1) .business search: "pizzeria", "via del corso, roma" MOVE client : sd: Business search − Automatic provider: fallback GoogleMaps : YahooMaps : 5) [results] 5) .business search: "pizzeria", "Via del Corso, 00186 Rome RM Italy" 4) "Via del Corso, 00186 Rome RM Italy" 4) .address search: "via del corso, roma" 3) [exception] 3) .business search: "pizzeria", "via del corso, roma" Automatic : MSNLiveLocal: 3.4 Requirements analysis 30 Figure 3.4: SMSNavigatorProxy – Sequence diagram: Business search - Automatic provider, fallback. 3) options for "via del tritone" 3) .route_search: "Via del Corso, Roma", "via del tritone" 1) options for "via del corso" 1) .route_search: "via del corso", "via del tritone" 6) route directions 8) "Via del Tritone, Roma" 8) .address_search: "Via del Tritone, Roma" 7) "Via del Corso, Roma" 7) .address_search: "Via del Corso, Roma" 5) multiple options for "via del tritone" 5) .address_search: "via del tritone" 4) "Via del Corso, Roma" 4) .address_search: "Via del Corso, Roma" 2) multiple options for "via del corso" 2) .address_search: "via del corso" 9) route directions as XML data 9) .route_search: "Via del Corso, Roma", "Via del Tritone, Roma" SMSNavigatorProxy : 6) .route_search: "Via del Corso, Roma", "Via del Tritone, Roma" MOVE client : sd: Route search with ambiguous source address and ambiguous destination address Map provider : 3.4 Requirements analysis 31 Figure 3.5: SMSNavigatorProxy – Sequence diagram: route search with both source and destination address ambiguous. 3.4 Requirements analysis 32 provider=MSNLiveLocal and the request does not contain the variable mr. error is sent back to the MOVE client. An provider=Automatic and the request does not contain at least one of the variables of the variable groups gx-gy-gz, yx-yy-yz, mr. An error is sent back to the MOVE client. The value of the variable provider does not correspond to any available provider, or there is an error during object instantiation An error is sent back to the MOVE client. An error during the request to the map provider occurs. back to the MOVE client. 3.4.2 An error is sent Class diagram The identified classes are: MapProvider models a generic map provider. GoogleMaps models the Google Maps map provider. Subclass of MapProvider YahooMaps models the Yahoo Maps map provider. Subclass of MapProvider MSNLiveLocal models the MSN Live Local map provider. Subclass of MapProvider Automatic models the Automatic map provider, providing transparent fallback of requests from Google Maps to Yahoo Maps and MSN Live Local in case of errors. Subclass of MapProvider AddressResultset holds an address search resultset and assembles response for the MOVE client. BusinessResultset holds a business search resultset and assembles response for the MOVE client. RouteResultset holds a route calculation resultset and assembles response for the MOVE client. Exception classes model various error situations. For the class diagram of the classes MapProvider, GoogleMaps, YahooMaps, MSNLiveLocal and Automatic, refer to figure 3.6. For the class diagram of the classes AddressResultset, BusinessResultset and RouteResultset, refer to figure 3.7. MapProvider GoogleMaps MSNLiveLocal + address_search ($place :string ):AddressResultSet + business_search ($what :string ,$near :string ):AddressResultset|BusinessResultset + route_search ($saddr :string ,$daddr :string ):AddressResultset|RouteResultset + get_map_tile ($location :array ):void + set_language ($lang :string ):void −$language :string + address_search ($place :string ):AddressResultSet + business_search ($what :string ,$near :string ):AddressResultset|BusinessResultset + route_search ($saddr :string ,$daddr :string ):AddressResultset|RouteResultset + get_map_tile ($location :array ):void + set_language ($lang :string ):void −$key :string YahooMaps + address_search ($place :string ):AddressResultSet + business_search ($what :string ,$near :string ):AddressResultset|BusinessResultset + route_search ($saddr :string ,$daddr :string ):AddressResultset|RouteResultset + get_map_tile ($location :array ):void + set_language ($lang :string ):void + encodePolyline ($pointsString :string ):string + decodePolyline ($a:string ):array −encodeSignedNumber ($num :double ):string −$key :string −$language :string + address_search ($place :string ):AddressResultSet + business_search ($what :string ,$near :string ):AddressResultset|BusinessResultset + route_search ($saddr :string ,$daddr :string ):AddressResultset|RouteResultset + get_map_tile ($location :array ):void + set_language ($lang :string ):void cd: SMSNavigatorProxy − Class diagram Automatic + __construct (): + address_search ($place :string ):AddressResultSet + business_search ($what :string ,$near :string ):AddressResultset|BusinessResultset + route_search ($saddr :string ,$daddr :string ):AddressResultset|RouteResultset + get_map_tile ($location :array ):void + set_language ($lang :string ):void −$language :string −$google :GoogleMaps −$yahoo :YahooMaps −$msn :MSNLiveLocal 3.4 Requirements analysis 33 Figure 3.6: SMSNavigatorProxy – Map providers’ class diagram. 3.4 Requirements analysis 34 cd: SMSNavigatorProxy − *Resultset class diagram AddressResultset + $resultset :array + $additionaldata :string + __construct ($resultset :array ,$additionaldata=’−’ + toString ():string BusinessResultset :string ): RouteResultset + $resultset :array + $resultset :array + __construct ($resultset :array ): + toString ():string + __construct ($resultset :array ): + toString ():string Figure 3.7: SMSNavigatorProxy – *Resultset class diagram. 3.4 Requirements analysis 35 cd: SMSNavigatorProxy − Exception hierarchy SMSNavigatorProxyException LocalIOException ServiceUnavailable MapProviderException NetworkProblemException NonExistentAddressException Figure 3.8: SMSNavigatorProxy – Exceptions class diagram. 3.5 Implementation 3.5 3.5.1 36 Implementation Dynamic content generation: PHP SMSNavigatorProxy is implemented in PHP 5. PHP (PHP: Hypertext Preprocessor ) [13] is a widely-used general-purpose scripting language that is especially suited for web development and can be embedded into HTML. It generally runs on a web server, taking PHP code as its input and creating web pages as output. It can be deployed on most web servers and on almost every operating system and platform free of charge. Reasons for its adoption have been mainly the fact that the business search feature of MSN Live Local was already implemented in PHP and no other solutions have become available. Besides, PHP was already installed, configured and optimized on the production web server. Last, but not least, its simplicity and power, crossplatform support, ease of deployment made this language one of the most popular server-side scripting. Its syntax has been heavily influenced from C, C++ and Java. Unlike those language, though, PHP offers weak type discipline, meaning that the data types do not need to be specified in advance when declaring variables, and dynamic typing, meaning that type checking is performed during run-time (also known as “late-binding”). Variables are prefixed with a dollar symbol. Since version 5, released in July 2004, PHP features an extended object-oriented functionalities. Objects are referenced by handle, and not by value. PHP 5 introduced private and protected member variables and methods, along with abstract classes and final classes as well as abstract methods and final methods. It also introduced a standard way of declaring constructors and destructors, similar to C++, and a standard exception handling model, similar to Java. Furthermore, PHP 5 added interfaces and allowed for multiple interfaces to be implemented. The most common configuration of the PHP interpreter inside the Apache web server is as an Apache module. An Apache module is a compiled library written according to the Apache module API and load dinamically by Apache’s core. Handling requests Requests to the web server are made by sending the HTTP’s GET or POST method. The first implies sending data (intended as pairs variable_name,value) as part of the URL of the resource. Because of this, the amount of data that can be sent for each request is limited to the maximum length of the URL (tipically ∼ 2000 characters, depends on browser). The second implies sending data as the body of the method. In this case, the amount of data is only limited by the value configured in the web server. The pairs variable_name,value of the GET method are made conveniently available by the PHP language via the associative array $_REQUEST: 1 // get the value of the GET variable var1 3.5 Implementation 37 2 $x = $_REQUEST[’var1’]; Handling responses Dynamic content can be provided by the web server by invoking the PHP interpreter module after loading the requested resource from local storage. At this point, the PHP interpreter parses and executes the scripting code (enclosed in tags ). The standard output of the code is the HTML resource’s body. On completion, the returned HTML code is forwarded to the web server, which produces an HTTP response and sends it to the client. XML parsing XML documents can be parsed by using the SimpleXML library. The approach used by this library, called DOM model [14], involves parsing the XML code completely, and then generating and returning an appropriate data structure that holds the data and the structure of the document. The DOM model is opposed to SAX model [15], which is a stream parser with an event-driven API. The user defines a number of callback methods that will be called when events occur during parsing. 3.5.2 Main code The code executed first is located in the smsnavigator.php file. First of all, the value of the GET variable a is tested. If it is search, the search() function is called; else, if it is maptile, the get_map_tile() function is called. The search() function The value of the variables hl and provider is obtained. If the provider variable is missing, it is set to Automatic. Then, a map provider object is instantiated by calling the factory method and passing to it the provider name. Finally, according to the value of mode, the corresponding method of the map provider object is called, passing the appropriate parameters. Map provider instantiation using a factory method Map providers are instantiated using a factory method. The factory method pattern is a creational object-oriented design pattern which deals with the problem of creating objects without specifying at compile time their exact class. Recalling the class diagram of figure 3.6, each map provider is a subclass of MapProvider. The provider class named X must be defined in the file X.class.php. By calling the istantiate factory method and passing the provider name X (as a string) to it, the corresponding file X.class.php is include_once’d. Then, a new X object is dynamically loaded and returned, simply by doing: 3.5 Implementation 38 return new $class; where $class is a string variable containing the literal X. If the provider class file cannot be found, an Exception is thrown. The get_map_tile() function The value of the variable provider is obtained. If the provider variable is missing, it is set to Automatic. Then, a map provider object is instantiated by calling the factory method and passing to it the provider name. Then, depending from it, the provider-specific set of variables denoting coordinates is extracted. Such values are assembled into an associative array, whose keys have the same name than GET variable names (gx, gy. . . ). Finally, the get_map_tile() method of the provider object is invoked, passing that array as parameter. Error handling As reported in the class diagram 3.8, a custom exception hierarchy has been defined. When an exception belonging to this hierarchy is forwarded by inner method calls in the call stack and it is catched by search() or get_map_tile(), the error_handler() function is called. This functions provides an unified logging facility, which logs error independently on the standard output or in a log file on the server. 3.5.3 The Google Maps map provider As presented in section 2.2.1, all Google Maps’ services are KML based. The URL to use for requests toward Google Maps for each service is reported in the before mentioned section as well. Address search Address search output is downloaded by invoking the function download, and returned as a string. XML parsing of the response is made using the SimpleXML functions provided natively by PHP. First of all, the Response->Status->code value is tested against the values in table 3.3. If the return code is 200, the XML code of the response is parsed and iterated to extract the tokens of interest. In detail, it is necessary to iterate over Response->Placemark objects: for each item, the address attribute and the first two components of the attribute Point->coordinates (by tokenizing around the comma) are extracted. These values are pushed into an associative array with the keys address, lat and lon. This array is then pushed in the results array. This functions returns a new AddressResultset object, created by passing the associative array with the results to its constructor. One function call up in the stack, the search() function will echo the AddressResultset object, causing the automatic 3.5 Implementation Code 200 500 601 602 603 610 620 Meaning No errors occurred; the address was parsed and located and its geocode location has been returned. Geocoding request could not be successfully processed, yet the exact reason is unknown. The q parameter was either missing or had no value. The address was given but no corresponding geographic location could be found. This may be because this address is relatively new or is incorrect. The address is valid, but for legal or other reasons, geocoder may not return its coordinates. The API key given with the request does not appear valid. There were too many requests issued for the given site within the 24h period. 39 Exception (none) MapProviderException NonExistentAddressException NonExistentAddressException NonExistentAddressException MapProviderException MapProviderException Table 3.3: KML 2.1 Reference – Geocoding return codes. Also see [7]. invocation of its method __toString(). This method contains the rules about how to assemble the response. As the search() function is on top of the call stack, the PHP interpreter returns control to Apache, which will serve the dynamic resource assembled by AddressResultset::__toString(). An example of the structure of the resultset array incapsulated into the AddressResultset object is available in code 3.13. Business search Business search is a little less straightforward than address search, as its error handling is practically null. First of all, the address has to be tested for ambiguity: this is easily done by invoking the GoogleMaps::address_search() method. If the number of returned results is exactly 1, the address is not ambiguous. In this case, the actual business search request is made toward Google Maps by retrieving the resource at the appropriate URL. To download the resource, the download function is used. If the length of the retrieved resource is 0, either: • The business name is incorrect (e.g. mispelled) • There are no businesses of the specified category near the specified address • Google is having technical problems In this case, a new BusinessResultset object containing an empty array of results is returned. If the length of the retrieved resource is not 0, the XML response is parsed and iterated for over Folder->Placemark. The associative array containing each result is assembled as follows: 3.5 Implementation 40 1 Array 2 ( 3 [0] => Array 4 ( 5 [address] => Via Casilina, Roma, Roma (Lazio), Italy 6 [lat] => 12.683648 7 [lon] => 41.862152 8 ) 9 10 [1] => Array 11 ( 12 [address] => Via Casilina, Italy 13 [lat] => 13.982522 14 [lon] => 41.413610 15 ) 16 ) Code 3.13: Results array for addresses, obtained by the PHP’s function print_r. name => name address => Snippet[0] (first token obtained after splitting Snippet around
) phone => Snippet[1] (second token obtained after splitting Snippet around
) lat => Point->coordinates[0] (first token obtained after splitting Point->coordinates around the comma) lon => Point->coordinates[0] (second token obtained after splitting Point->coordinates around the comma) Each of these arrays is then pushed in the results array. The function then returns a new BusinessResultset object containing the results array, and whose __toString() method is automatically invoked when the caller function search() echoes the object to the standard output. An example of the structure of the resultset array incapsulated into the BusinessResultset object is available in code 3.14. If the address is ambiguous, the function returns a new AddressResultset object containing the array of choices got from the address search. Route calculation Route calculation does not offer explicit error notification as well. So, both the source and the destination address have to be checked for ambiguity by doing a preliminar address_search() on them. If one of them is ambiguous, the list of choices got from the address search is encapsulated into an AddressResultset, and the $additionaldata parameter of its constructor is set either to OPTsaddr or to OPTdaddr, depending on which address 3.5 Implementation 41 1 Array 2 ( 3 [0] => Array 4 ( 5 [name] => Baldi 6 [address] => Via Del Leoncino, 28, 00186 Roma (RM), Italy 7 [phone] => 06 6867757 8 [lat] => 12.478076 9 [lon] => 41.904383 10 ) 11 12 [1] => Array 13 ( 14 [name] => Appia Nuova 2003 S.R.L. 15 [address] => Via Della Mercede, 45, 00187 Roma (RM), Italy 16 [phone] => 06 6786015 17 [lat] => 12.482035 18 [lon] => 41.903237 19 ) 20 ) Code 3.14: Results array for businesses, obtained by the PHP’s function print_r. is ambiguous. For a description on how this data field is used when assembling response, refer to section 3.3.3. The sequence diagram 3.5 shows the interaction with the MOVE client when both the addresses are ambiguous. If both the addresses are not ambiguous, the XML response is parsed and iterated over Document->Placemark. The associative array containing each result is assembled as an associative array with the following structure: direction => name distance => description lat => Point->coordinates[0] (first token obtained after splitting Point->coordinates around the comma) lon => Point->coordinates[0] (second token obtained after splitting Point->coordinates around the comma) For each iteration, $center_lat, $center_lon, $span_lat and $span_lon are updated. Finally, a RouteResultset object containing an array which, in turn, contains the array of directions, $center_lat, $center_lon, $span_lat and $span_lon is returned. An example of the structure of the resultset array incapsulated into the RouteResultset object is available in code 3.15. 3.5 Implementation 1 Array 2 ( 3 [steps] => Array 4 ( 5 [0] => Array 6 ( 7 [direction] => Head south on Via del Corso toward Via in Lucina 8 [distance] => 0.2 km 9 [lat] => 12.479480 10 [lon] => 41.903200 11 ) 12 13 [1] => Array 14 ( 15 [direction] => Turn left at Largo Chigi 16 [distance] => 87 m 17 [lat] => 12.480190 18 [lon] => 41.901540 19 ) 20 21 [2] => Array 22 ( 23 [direction] => Continue on Via del Tritone 24 [distance] => 0.3 km 25 [lat] => 12.481190 26 [lon] => 41.901780 27 ) 28 29 [3] => Array 30 ( 31 [direction] => Arrive at: Via del Tritone, 00187 Rome RM, Italy 32 [distance] => 33 [lat] => 12.484100 34 [lon] => 41.902470 35 ) 36 37 ) 38 39 [center_lat] => 12.48179 40 [center_lon] => 41.90237 41 [span_lat] => 0.0023099999999996 42 [span_lon] => 0.00083000000000055 43 ) Code 3.15: Results array for waypoints, obtained by the PHP’s function print_r. 42 3.5 Implementation 43 Map tile retrieval First of all, the provider-specific local cache directory for maptiles is read from the configuration file, and it is checked whether the web server has permissions to write in it. Then, it is checked whether the requested maptile is available in cache: if yes it is loaded and sent directly to the MOVE client, otherwise a request to Google Maps is made and the downloaded maptile is stored into the cache. It is important to notice that, in such requests, at least the user-agent must be submitted as header, otherwise Google will not serve the request. The downloadToFile function is used to download the file directly to mass storage. 3.5.4 The Yahoo Maps map provider Address search As specified in table 3.2, Yahoo Maps only offers address search. Unlike Google Maps, the return code is not provided inside the XML response data, but it is actually the HTTP response code. For this reason, to download the resource, it is necessary to use the download_with_response() function, which returns an associative array containing the response code under the key serverResponse and the actual resource under the key fileContent. The meaning of error codes is like standard HTTP’s: 200 if the request was processed successfully, 400 in case of errors. Once got the XML, it is parsed via SimpleXML and iterated over Result nodes. Each result is then assembled as an associative array with the following structure: address => combination of Address, City, State as in “Via del Corso, 00186 Rome RM Italy” (see next section 3.5.5 for details) lat => Latitude lon => Longitude Each of these arrays is pushed into the results array, which will be encapsulated into an AddressResultset object and returned by the function. Map tile retrieval Yahoo Maps’ map tile retrieval is practically identical to Google Maps’ (see section 3.5.3. 3.5.5 The MSN Live Local map provider Business search Unlike the other two map providers previously examined, MSN Live Local does not offer any XML-based solution for automatic querying. The implementation of business search of the previous solution has then been taken nearly unaltered. 3.5 Implementation 44 Once received the XHTML code of the response, a regular expression checks whether results were found by testing for the absence of a div whose id is NoResultsControl. If there are results, geographic coordinates are extracted by splitting the text after the token mapLatLongs around the comma. The business name and the phone number are then extracted from the text arounf the token . These pieces of data are assembled into associative arrays, which are, in turn, assembled into the results array. This is encapsulated into a BusinessResultset and returned by the function. Notice that this method has no error checking or recovery, as is is not possible to discriminate errors based on the output format received. Hence, detectable errors such as ambiguous address or map provider issues are reported to the MOVE client as a generic error. Map tile retrieval MSN Live Local’s map tile retrieval is practically identical to Google Maps’ (see section 3.5.3. 3.5.6 The Automatic map provider Address search Having written address search methods using exceptions and a separate object to assemble the response, writing a Google Maps address search with automatic fallback to Yahoo Maps is quite easy, as reported in code 3.16. 1 public function address_search($place) 2 { 3 try 4 { 5 return $this->google->address_search($place); 6 } 7 catch (MapProviderException $mpe1) 8 { 9 return $this->yahoo->address_search($place); 10 } 11 } Code 3.16: Address search with automatic fallback. This way, if GoogleMaps::address_search() throws an exception, the same request is made again by invoking YahooMaps::address_search(). If even Yahoo Maps throws an exception, this it is not caught and rather forwarded to the caller, namely the search() function, which catches it and calls the error handling function. The same considerations about response assembly using AddressResultset objects made before apply here as well. 3.5 Implementation 45 Business search Business search with automatic fallback (see code 3.17) makes the business search request to Google Maps. If an exception is thrown, it is caught and the fallback mechanism starts. Recall that the only other map provider offering business search capability is MSN Live Local which, though, requires a very precise address as input. This address is obtained by invoking Yahoo Maps’ address search, and formatting the geocoded address the way MSN expects it to be. Notice that if Yahoo Maps’ address search fails, the business search request toward MSN is made anyway using the user-entered address3 . 1 public function business_search($what, $near) 2 { 3 try 4 { 5 return $this->google->business_search($what, $near); 6 } 7 catch (MapProviderException $mpe1) 8 { 9 try 10 { 11 $results = $this->yahoo->address_search($near); 12 if (count($results->resultset) == 1) 13 { 14 $near = urlencode($results->resultset[0][’address’]); 15 } 16 else 17 { 18 return $results; // address is ambiguous: send options back to MOVE client 19 } 20 } 21 catch (MapProviderException $mpe) 22 { 23 /* 24 * It is not compulsory to do geocoding with Yahoo in order to do a 25 * business search with MSN, so we don’t abort here, but continue. 26 * However, it is highly probable that MSN won’t recognize the 27 * address, especially if it is written liberally ("via del tritone, 28 * roma" VS "Via del Tritone, 00187 Roma RM, Italy") 29 */ 30 } 31 return $this->msn->business_search($what, $near); 32 } 33 } Code 3.17: Business search with automatic fallback. 3 This, as seen, will most probably fail. . . 3.6 Integration in the MOVE client 46 Route calculation No map provider other than Google Maps offers route calculations, so this method merely invokes GoogleMaps::route_search(). Map tile retrieval Map tile retrieval with automatic fallback uses the same concept seen above: if a map provider throws an exception, use the next one. Nothing fancy has to be said about the code, reported in code 3.18. 1 public function get_map_tile($location) 2 { 3 try 4 { 5 $this->google->get_map_tile($location); 6 } 7 catch (NetworkProblemException $npe) 8 { 9 try 10 { 11 $this->yahoo->get_map_tile($location); 12 } 13 catch (NetworkProblemException $npe) 14 { 15 $this->msn->get_map_tile($location); 16 } 17 } 18 } Code 3.18: Map tile retrieval with automatic fallback. 3.6 Integration in the MOVE client This section explains the changes that have been made to the MOVE client code. This work has been done on MOVE client 1.04 alpha 03, and then integrated, among changes in other portions, in the ‘trunk’ branch. The source code can be downloaded from http://minerva.netgroup.uniroma2.it/sms. 3.6.1 navigator/smsnavigator/MapTileManager.java The MapTileManager class contains map tile management logic. The only modified function is download(). It is used to retrieve the maptile image corresponding to the MapTile object passed as parameter by making an appropriate request to SMSNavigatorProxy. During construction of the URL to use to retrieve the maptile, the chosen map provider saved in Navigator’s preferences (the setting named mapsEngine) is checked. This is done in order to add to the GET method of 3.6 Integration in the MOVE client 47 the request the correct set of coordinate variables only: gx-gy-gz if mapsEngine is Google Maps, yx-yy-yz if it is Yahoo Maps, mr if it is MSN Maps, all of the above if it is Auto. 3.6.2 navigator/smsnavigator/PrefsEditor.java This class is a form which allows the user to set certain preferences for the Navigator, among which the map provider to be used. A new item for the Automatic map provider has been added in the combo box containing map provider possible choices. This has been accomplished by modifying the getMapsEngineArray() function. The getIndexMapsEnginePreference() function, which returns an integer corresponding to the map provider in use, has also been modified to give a correct result when the Automatic map provider is chosen. 3.6.3 navigator/smsnavigator/SearchMenu.java This class deals with request/response handling of the three search types. Support for selectable map provider has been added: the submitSearch() has been modified to include the GET variable provider to the request and to set its value to the current provider in use. Compliance with the new route search response format (see section 3.3.2) has been introduced. In function submitSearch(), the polyline decoding code block has been removed and the parsing and extraction of waypoint coordinates has been joined to address search’s and business search’s, as the three formats are now identical. Address ambiguity management for route searches has been also updated. For more details, refer to section 3.3.3. Chapter 4 Future developments and conclusions Section 4.1 contains some proposals for future enhancements and guidelines about how to implement a new map provider. Section 4.2 focuses on the overall accomplishments obtained at the end of this thesis work. 4.1 Future developments The most effective extension that can be made in the near future is the implementation of new map providers. As ease of expansion was one of the design goals, adding new map providers is a relatively easy task. The following guidelines should be followed: 1. Create a MyProvider class, which extends the MapProvider class, inside the new file MyProvider.class.php. As seen, thanks to the use of a factory method to instantiate provider objects and PHP’s dynamic class loading, nothing more has to be changed to use the new map provider: it is enough to specify it as the value of the provider GET variable in the request. 2. Redefine abstract methods address_search, business_search, route_search and get_map_tile. If the map provider does not support one of these search types, or you want to make it unavailable for any reason, redefine the corresponding method to throw a ServiceUnavailable exception. 3. Inside these methods, assemble the raw data extracted from the map provider’s response (address, coordinates, etc.) as one of the appropriate arrays, which are here summarized for the reader’s convenience: Results array for addresses Contains one associative array per result. Each associative array must use the keys address, lat, lon. For an example, refer to code 3.13 on page 40. 4.2 Conclusions 49 Results array for businesses Contains one associative array per result. Each associative array must use the keys name, address, phone, lat, lon. For an example, refer to code 3.14 on page 41. Results array for waypoints Contains: • a steps associative array which, in turn, contains one associative array per waypoint. Each waypoint array must use the keys direction, distance, lat, lon • a center_lat entry • a center_lon entry • a span_lat entry • a span_lon entry For an example, refer to code 3.15 on page 42. 4. Do not return the results array of the previous point directly but, instead, return a freshly created AddressResultset, BusinessResultset or RouteResultset object containing those results. This will ensure that the response format will be parsable my the MOVE client. 5. If you want to provide cached map tile retrieval, add a new option to the smsnavigator.conf.php configuration file, specifying the absolute or relative path of the cache directory to use for your provider’s maptiles. 6. Your search methods should use the declared exceptions in order to notify errors to the MOVE client in a consistent manner with respect to other map providers. 7. You may want to use the functions available in the file smsnavigator.conf.php to download a file. 4.2 Conclusions At the end of this thesis work, the improvements carried out to SMSNavigatorProxy with respect to the previous solution are several: • Data retrieval from map providers has been stabilized by using XML and, so, decoupled from changes in the presentation HTML code. MSN Live Local is the only provider which still uses the old approach of extracting data from pages by regular expressions, because it does not offer XML support. • The structure of SMSNavigatorProxy has been redesigned from scratch, in order to allow the most painless possible future expansion by adding, as explained in the previous section, new map providers and other features. 4.2 Conclusions 50 • The request format has been extended and streamlined, by reorganizing GET variables name and meaning. For example, the current variable address is the result of merging the two variables near and q of the old solution. • The route search response protocol and the corresponding portions of the MOVE client have also been greatly simplified by the elimination of the polyline and its related decoding and management. Appendix A Map services output examples In this appendix, examples of the XML code returned by the map providers supporting it is returned. A.1 Google Maps A.1.1 Address search KML geocoding output for “via del politecnico, roma”. 1 2 3 4 via del politecnico, roma 5 6 200 7 geocode 8 9 10
Via del Politecnico, 00133 Roma, Roma (Lazio), Italy
11 12 13 IT 14 15 Lazio 16 17 Roma 18 19 Roma 20 21 Via del Politecnico 22 23 24 00133 25 26 A.1 Google Maps 52 27 28 29 30 31 32 12.618403,41.854170,0 33 34 35 36 A.1.2 Business search KML output for restaurant search near “via del tritone, roma”. 1 2 3 4 restaurant near via del tritone, roma 5 1 6 7 Printable view
Business listings provided by PagineGialle.it]]> 9 10 11 12 Ristorante Giapponese Shinto - Sushi Restaurant 13 14 06 42827380]]> 16 17
Via Ludovisi, 39/41<br/>00187 Roma (RM), Italy
18 root://styleMaps#default+nicon=0x500+hicon=0x510 19 20 21 22 23 24 25 12.488220,41.906924,0 26 27 28 29 30 31 32 A.1 Google Maps A.1.3 53 Route calculation KML output for route calculation from “via del corso, roma” to “via del tritone, roma”. 1 2 3 4 Via del Corso, Rome RM, Italy to Via del Tritone, 00187 Rome RM, Italy< /name> 5 11 12 Printable view]]> 13 14 15 Head south on Via del Corso toward Via in Lucina 16 17 18 19
Via del Corso, Rome RM, Italy
20 root://styleMaps#default+nicon=0x406+hicon=0x416 21 22 12.479480,41.903200,0 23 24 25 12.479480 26 41.903200 27 100.000000 28 45.000000 29 162.341492 30 31 32 33 Turn left at Largo Chigi 34 35 36 37 root://styleMaps#default+nicon=0x447+hicon=0x457 38 39 12.480190,41.901540,0 40 41 42 12.480190 43 41.901540 44 100.000000 45 45.000000 46 162.341492 A.2 Yahoo Maps 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 54 Continue on Via del Tritone root://styleMaps#default+nicon=0x447+hicon=0x457 12.481190,41.901780,0 12.481190 41.901780 100.000000 45.000000 72.127541 Arrive at: Via del Tritone, 00187 Rome RM, Italy
Via del Tritone, 00187 Rome RM, Italy
root://styleMaps#default+nicon=0x467+hicon=0x477 12.484100,41.902470,0 Route Map data ©2008 Tele Atlas ]]> 12.479480,41.903200,0.000000 12.480190,41.901540,0.000000 12.480190,41.901540,0.000000 12.481190,41.901780,0.000000 12.481190,41.901780,0.000000 12.484100,41.902470,0.000000 #roadStyle A.2 A.2.1 Yahoo Maps Address search XML output for “via del politecnico, roma”. A.2 Yahoo Maps 55 1 2 3 4 41.854915 5 12.617530 6
via Politecnico
7 00133 Rome RM 8 Italy 9 10 IT 11 12 13