50
Project Work Google Maps, Skyscanner and eStreaming APIs for collecting and presenting travel route information Florian Henke January 22, 2018 Mentor: Prof. Dr. Wolfgang May

Google Maps, Skyscanner and eStreaming APIs for collecting

  • Upload
    others

  • View
    9

  • Download
    0

Embed Size (px)

Citation preview

Page 1: Google Maps, Skyscanner and eStreaming APIs for collecting

Project Work

Google Maps, Skyscanner and eStreaming APIsfor collecting and presenting travel route

information

Florian Henke

January 22, 2018

Mentor:Prof. Dr. Wolfgang May

Page 2: Google Maps, Skyscanner and eStreaming APIs for collecting

Abstract

This report describes how to work with the main Google Maps API’s, especially the Dis-tance Matrix API, the Direction API and the JavaScript API and the APIs from the flight searchpage Skyscanner.com and eStreaming. This is shown on an use case application namedTripPlanner that shows how these APIs can work together by finding the best path fromone place in the world to any other. Prerequisites to understand the content of this reportare basic knowledge in Java, JavaScript and PHP.

ii

Page 3: Google Maps, Skyscanner and eStreaming APIs for collecting

Contents

1. Introduction 1

2. Google Maps 22.1. Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1.1. API Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.1.2. Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.1.3. Polylines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2. Side APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2.1. Auto Complete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2.2. Geocoding API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2.3. Time Zone API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.3. JavaScript API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.3.1. Initialize Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.3.2. Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.4. Direction API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.4.1. Elements of Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.4.2. Return Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.5. Distance API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.5.1. Elements of Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.5.2. Return Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3. Skyscanner 243.1. API access and restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.2. Place APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.3. Cache APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.4. Live Price APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.5. How to do a Query . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4. eStreaming 284.1. API access and restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.2. Available APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.3. How to do a Query . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5. Trip Planner Application 315.1. Important Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315.2. API Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

5.2.1. Google Maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335.2.2. Skyscanner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345.2.3. eStreaming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

5.3. Cached Flight Connection Database . . . . . . . . . . . . . . . . . . . . . . . . . . 355.4. Path Finding Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365.5. Graphical User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375.6. Communication between Server and Client . . . . . . . . . . . . . . . . . . . . . . 39

6. Conclusion and Further Research 40

List of Figures 41

References 42

iii

Page 4: Google Maps, Skyscanner and eStreaming APIs for collecting

A. Appendix IA.1. Statistic Queries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I

A.1.1. All Airport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IA.1.2. All served Airport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IA.1.3. Different direct connections . . . . . . . . . . . . . . . . . . . . . . . . . . . IA.1.4. Different connected connections . . . . . . . . . . . . . . . . . . . . . . . . IA.1.5. Total flightsflights all in all in time periode . . . . . . . . . . . . . . . . . . IA.1.6. Amount of flights . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II

iv

Page 5: Google Maps, Skyscanner and eStreaming APIs for collecting

1. Introduction

Usually flight search engines are able to find connections provided by only one carrier like anairlines or a cooperation of airlines. Even so that a lot of big airlines are cooperated with air-lines from other countries to provide as many different connections as possible the flight searchengines can’t find connections to a lot of places on the world even from big airports like Frank-furt or Beijing. However, often even good connections are exist to these places but it wouldbe necessary to switch between different airlines on the journey. But in this case the customercarries the whole risk. If a travel agency would sell a connection where the customer have toswitch between different airlines the agency would carry the whole risk. For the case that thefirst flight is late or even canceled and the connected flight can’t be reached on time the agencywould have to bother for a new connection. Therefore the travel search agencies don’t providethis kind of connections. But also search engines that just show possible connections which areno travel agencies that sell the flights as a single journey don’t provide connections where thecustomer has to switch between different airlines usually. The reason therefor is simple. It isvery complex, non-trivial and computing intensive to find a good connection by consideringall flights available from all airlines on the world.

The first step to find a connection before starting to calculate the best path is to get access toflight data. This is already a very complicate task because each airline has a different API forits flight data and provides even different data through its API compared to its combatants. OnJanuary 12th 2018 424 different airlines are registered by IATA [IAT]. That means to get a fulldata set, 424 different API’s which can change its syntax very often, would be necessary. SomeCompanies like Skyscanner, ITA Matrix Search or eStreaming are specialized to collect these dataand provide it as a single API [ITA] [Skyb] [eSt]. But to get live data from these APIs is usuallynot free of charge and the data of these APIs are also not complete [ITA] [eSt]. Therefore thisreport deals mainly with the question how to get flight data and how to cache them.

After the introduction different APIs are described. The second section describes the APIs pro-vided by Google Maps, the third section the APIs provided by Skyscanner and the fourth sectionthe APIs provided by eStreaming. The fives section describes how the application developed forthis report collects flight data and how it cashes these data. Additionally, the section describessimple methods of path calculation which are already implemented. The last section gives ashort overview about this report and hints some further researches that could build up on thisreport.

1

Page 6: Google Maps, Skyscanner and eStreaming APIs for collecting

2. Google Maps

Google provides a huge range of APIs for a lot of different fields related to map use. The APIsare splitted in two groups, the web APIs and the web-service APIs. The web APIs are all theseAPIs which can be embedded through JavaScript directly on the client side [Gool] and the webservice APIs are these APIs which have to be accessed throughout an HTTP call from the serverside [Gooo].As web APIs Google offers [Gool]:

• Google Maps JavaScript API: The Google Maps JavaScript API enables the implementationof an interactive Google Map into an HTML page. With this API it is possible to addmarkers, lines, figures, info windows and much more on the map. It also allows thedeveloper to customize the displayed map. In Section 2.3 the Google Maps JavaScript APIwill be described in detail.

• Google Maps Embed API: This API allows people with no coding skills to use GoogleMaps with a lower functionality in an HTML page as well [Goom].

• Google Street View Image API: This API enables the developer to embed Google Streetviewinto an HTML page. By entering a location and a viewing direction this API returns theGoogle Maps Street View panorama picture [Goor].

• Google Static Maps API: Shows a customized map as a picture on an HTML page with-out any interactive elements. The advantage is that this method is fast and simple becauseno JavaScript is required and that this API has an unlimited free daily contingent [Gooq].

• Google Places API JavaScript-Library: This library of the Google Maps Java Script API al-lows to access data about over 100 million places on the whole world like cites, countries,businesses, locations and many more. For every place data like address, name, openinghours, rating and more are available. This library also allows auto completion of placesas described in Section 2.2.1 and the search of places near the current or any arbitrarylocation [Goou].

As web-service APIs Google offers [Gooo]:

• Google Maps Direction API: This API returns the fastest route and some alternativesbetween the given places. It includes the transit modes car, walk, bicycle and publictransport and considers the expected traffic based on the current and past traffic data. Adetailed description of this API can be found in Section 2.4 [Gooe].

• Google Maps Distance Matrix API: This API returns the distance and the duration be-tween several locations but not a full route description. This API can be called withseveral origin and destination addresses, in this case the distance and duration for allcombinations between origin and destination will be calculated and returned. The hugeadvantage of this API is, that it is much faster than the Google Maps Direction API. A de-tailed description of this API can be obtained from Section 2.5 [Goof].

2

Page 7: Google Maps, Skyscanner and eStreaming APIs for collecting

• Google Maps Geolocation API: This API returns the current location and the accuracyof the calculated location of the user based on data of mobile towers and the wifi network[Gooc].

• Google Maps Geocoding API: This API converts addresses to coordinates and coordi-nates or place IDs to full addresses. A more detailed description of this API can be foundin Section 2.2.2 [Goog].

• Google Places API: This API has the same functionality as the JavaScript library forplaces described above. The only difference is that this API can be called via a HTTPcall from the server side instead of a client side JavaScript call [Goop].

• Google Maps Elevation API: With this API it is possible to get for every location on theworld its elevation. This applies also for locations under zero meters over the see level.In this case a negative value will be returned [Gooh].

• Google Maps Roads API: This API calculates the roads the user was using based onmaybe not that accurate GPS tracking coordinates. This could also be done in real time.Additionally this API returns further information about the roads like speed limits [Good].

• Google Maps Time Zone API: By passing the coordinates of a location and a date to theGoogle Maps Time Zone API it will return information about the time zone and the timedifference to UTC time. Further information about this API in Section 2.2.3 [Gooi].

All web-service APIs can be called by an HTTP and an HTTPS call. But if the web page thatcalls the API uses HTTPS the API call has be use HTTPS as well. All parameters have to bepassed to the server via GET. It is not possible to pass them with POST.

Beside these APIs Google provides several APIs for iOS and Android as well as for Java,Python, Go and Node.js. To describe all these APIs in detail would exceed this project, butin general they work in the same way as the web APIs and the web service APIs.In this fastly changing environment it is definitely recommended to use the Google referencepages, that are always referred in this document, for implementation usage. This section islimited to a short overview of the possibilities given by the Google Maps APIs.

2.1. Utilities

Before describing the single APIs, few preliminaries will be described in this section. First therestrictions by using the Google Maps APIs will be explained and afterwards the Google Maps

Polyline concept is explained.

2.1.1. API Key

Each API call requires an API key for which the used API is enabled. This section describeshow to obtain such an API Key and how to enable the required APIs.

3

Page 8: Google Maps, Skyscanner and eStreaming APIs for collecting

Figure 1: Google API Dashboard.

Obtaining an API-Key Before requesting an API key a Google account has to be created, al-ternatively an existing Google account can be used. Then a key can be obtained from [Gooj]by pushing the Request Key button. Afterwards a project name has to be entered. The key canthen be read from the info box. For further settings and information about how to use the API,can be opened the dashboard throughout the link in the lower right corner.

Enabling an API For enabling an API for a key the dashboard has to be used. Thiscan be accessed directly after obtaining an API key as described above or by callinghttps://console.developers.google.com/apis/dashboard. The dashboard lists all enabled APIs andfurther information like requests in the last hour about them. To enable a new API the buttonENABLE APIS AND SERVICES on the upper center has to be pushed. Afterwards an API fromthe list can be selected, alternatively it can be searched for an API. After selecting an API theENABLE button has to be pushed. Now the API is enabled for the API key. To monitor howmuch of the daily contingent is used already, the menu button in the upper left corner of thedashboard window has to be pushed. Afterwards IAM & admin and then Quotas has to be se-lected. This will show a list with all used APIs and the corresponding request limit and thealready used requests.

2.1.2. Restrictions

Google Maps allows free, restricted access to their services for public, uncommercial use. Thelowest access restrictions apply for the mobile APIs. The Google Maps Android and iOS APIshave unlimited free access. The Google Place APIs have a still very high limit of 150,000 requestsa day. For the iOS and Android versions is it even possible to increase this free limit. TheGoogle Maps Embed API has also no limitations. The Google Maps Java Script, Static Maps andStreet View Image APIs are restricted to 25,000 loaded maps a day. The web services wich are therest of the APIs like Google Maps Direction or Elevation API are restricted to 2,500 requests a day.

4

Page 9: Google Maps, Skyscanner and eStreaming APIs for collecting

Google offers a simple way to increase the daily limit without entering a contract by paying 50cents for each 1,000 requests over the free limit up to 100,000 a day. For commercial or accessrestricted applications, other rules apply. But especially for Android applications there are stillfree opportunities available [Goov].

2.1.3. Polylines

Polylines are ordered lists of coordinates which generate a path by connecting each coordinatewith the next one by a line. They are used for showing a path received from the Google MapsDirection API on a Map.Polylines with a huge amount of points, for example for routes on streets are very memory-intensive. Especially sending such huge polylines through the internet is a problem. ThereforeGoogle has developed an encoding mechanism to compress polylines. The Google APIs likeGoogle Maps Direction API which is used in this project are using this encoding mechanism forsending the path of a route. This path has to be decoded before it can be passed to a polylineobject for displaying it on the map. This can be done by functions provided by Google ormanually. First the manual method will be described in this report and afterwards the functionsprovided by the Google Maps API will be described.The usual case is, that an encoded polyline is received and has to be decoded. This case isexplained now, the other way around works with the same steps in opposite order. An en-coded polyline is a string of ASCII chars between 64 and 127. The longitude coordinate forthe Institute of Computer Science in Göttingen for example is 9,94796 decoded and "w}u{@"encoded.

1. To decode this encoded polyline coordinate, first the characters has to converted into theASCII decimal number representing the corresponding character.

119 125 117 123 64

2. The next step is to subtract 63 from each number. This has been added to the numbers byencoding to ensure that all characters are printable and that they are not interpreted asnumbers.

56 62 54 60 1

3. Now the numbers have to converted to binary code. A binary block starting with a 0indicates that the next block represents the next coordinate. Accordingly a 1 in front of abinary block means that the next block still belongs to the same coordinate.

111000 111110 110110 111100 000001

4. The leading bit of every block has to be removed now

11000 11110 10110 11100 00001

5

Page 10: Google Maps, Skyscanner and eStreaming APIs for collecting

5. Now the order of the blocks has to be inverted.

00001 11100 10110 11110 11000

6. A one as the last bit of the rightmost block indicates that the coordinate is negative, inthis case the whole sequence has to be inverted. In this example the last bit is a zero, thatindicates that the coordinate is positive.

7. Now the whole sequence has to be shifted one position to the right.

000000 11110 01011 01111 01100

8. If the coordinate is negative (like figured out in step 6) the sequence has to be subtractedby one and the sequence has to be inverted again afterwards.

9. The sequence has to be converted to a decimal value.

994796

10. multiply the decimal value by 10−5

9.94796

If the coordinates are written back to a polyline array, it has to be considered that only theoffset of the next coordinate is encoded. A polyline object in Google Maps needs exact oneorigin and one destination coordinate. That means that every coordinate from the encodedpolyline except the first one has to be used as the second coordinate of the current polyline andthe first coordinate of the next polyline object [Gooa].

The Google Maps JavaScript API provides two functions for decoding and encoding poly-lines. The google.maps.geometry.encoding.decodePath(encodedPolyline) function which con-verts a given encoded polyline to a polyline array with LatLng Objects. The problemis that Google Maps sometimes requires LatLng Literals. In this case the result has tobe manually converted to the literal representation or the stringify function has to beused. If a given array of polylines should be, encoded Google Maps provides the functiongoogle.maps.geometry.encoding.encodePath(Array<LatLng>) , that encodes a given LatLng Array to

a encoded polyline [Goon].

2.2. Side APIs

Beside the Google Maps Java Script, Direction and Distance APIs which are solving the core prob-lems in the Trip Planner application, lots of smaller Google APIs are used to support the mainAPIs. These applications will be described in this section.

6

Page 11: Google Maps, Skyscanner and eStreaming APIs for collecting

2.2.1. Auto Complete

The auto complete is part of the Google Maps Java Script API. If a user starts entering an addressthe auto complete function offers some full addresses to insert. The addresses that will beoffered can be affected by different parameters passed to the auto complete function.

Function Call Before using the auto complete function the proper library has to be included.Therefore the parameter library with the value places has to be added to the Google Mapslibrary call and the place API has to be enabled for the used key on the Google Maps APIdashboard. Now, a full library call could look like this:

1 < s c r i p t s r c =" ht tps ://maps . googleapis . com/maps/api/ j s ? key=YOUR\_API\_KEY&l i b r a r y =places&c a l l b a c k =initMap " async defer ></ s c r i p t >

Code Snipped 1: Example for including the Java Script library

More information about initializing the map and the library call in section 2.3.1.After including the library, the auto complete constructor has to be called:

1 var autocomplete = new google . maps . p laces . Autocomplete (HTML−Element ,opt ions ) ;

Code Snipped 2: Example for including the Java Script library

The HTML-Element has to be the HTML input element of the type text where the auto completewindow should be added to. This parameter is essential.The options parameter expects an options object and is optional. The options object has fourparameters, types, bounds, componentRestrictions and placeIdOnly.

• types: Defines one or more types from the following list which are considered by autocomplete.

– geocode: Returns only geocoded results and no establishments

– address: Returns only geocoded results with a full address

– establishment: Returns only establishments and no geocoded results

– region: Returns only regions

– cities: Returns only cities

• bounds: The value of bounds is a LatLngBounds object. All results suggested by the autocomplete are located inside this rectangle.

• componentRestrictions: Restricts the results to a specified group. Currently the onlyavailable parameter is country, which expects a two letters ISO 3166-1 ALPHA-2 countrycode (for example "de" for germany).

• placeIdOnly: Instructs the result element only to return the place id, types and name ofthe place.

7

Page 12: Google Maps, Skyscanner and eStreaming APIs for collecting

All options can also be set and accessed with getters and setters. The following example showsan auto complete option object that returns only places of the type city in the rectangle of thegiven coordinates which are in France. From all results, only the place ID, the type and thename will be returned.

1 var opt ions = {2 types : [ ’ ( c i t i e s ) ’ ] ,3 componentRestr ic t ions : { country : ’ f r ’ } ,4 bounds : new google . maps . LatLngBounds ( { l a t : −33.8902 , lng : 1 5 1 . 1 7 5 9 } , { l a t

: −33.8474 , lng : 1 5 1 . 2 6 3 1 } )5 placeIdOnly : t rue6 } ;

Code Snipped 3: Example for an auto complete options object

The function autocomplete.bindTo(’bounds’, map) uses the bounds of the actual map view asbounds. A full list of all available options, parameters and methodes can be obtained from[Goob]

Accessing Return Values If the user chooses a place from the suggested auto complete places,a event named place_changed is called. Then the method getPlace() from the auto completeobject can be called to receive a PlaceResult object. This object includes detailed informationof the place like address, place ID, reviews, location and a lot more. A detailed list about allparameters of PlaceResult can be obtained from the Google Place API reference page [Goou].

2.2.2. Geocoding API

The Google Maps Geocoding API converts a given address to a coordinate (geocoding) or a givencoordinate or place ID to an address (reverse geocoding) [Goog].This service is available at the following URL:

https://maps.googleapis.com/maps/api/geocode/outputFormat?parameters

The outputformat can have one of the following values:

• json: returns the answer as a json file.

• xml: returns the answer as a XML file

As parameters a list of the following parameters in arbitrary order can be used. As the delimiterthe "&" char has to be used.

Geocoding For geocoding the essential parameters are:

• address: An address that starts with the most detailed element, like the house numberand ends with the most general element like the country. All spaces have to be replacedby a plus character. If the components filter from the optional parameters is used, it ispossible to waive the address parameter.

8

Page 13: Google Maps, Skyscanner and eStreaming APIs for collecting

• key: The API-key that has been obtained from Google Maps for access to the GoogleMaps APIs [Gook]. This key limits the contingent of a user.

The optional parameters are:

• components: This is a list of filters which are delimited by a "|" character. Every filterconsists of a component:value pair. Possible components are:

– route: Long or short name of a route (like street name).

– locality: A locality or a sublocality (like a city).

– administrative_area: An administrative area (like a region).

– postal_code: Postal code or postal code prefix.

– country: Country name or country code with two letters according to ISO 3166-1.

For a full list of optional parameters or further information conduct [Goog].

Reverse Geocoding Reverse geocoding returns the closest address available to the given co-ordinate or place ID. The essential parameters for reverse geocoding are:

• latlng or placeID: the latitude and longitude delimited by a comma. Alternative can aplaceId be used.

• key: the key pursue the same rules as for geolocation.

The optional parameters are:

• result_type: The result returns only addresses that match at least one of the passed ad-dress types. An address type could be a street_address, postal_code or country. A full listof all available address types can be obtained from [Goog]. It is possible to pass multipleaddress types by delimiting them by a "|" character.

• location_type: The result returns only addresses that match at least one of the passedlocation types. Supported values for location_type are:

– ROOFTOP: Only results that have a full postal address.

– RANGE_INTERPOLATED: Only results that have an approximation (usually on astreet) between two precise places (like corners).

– GEOMETRIC_CENTER: Only results that are the center of a place, for example apolyline (a street) or a polygon (a region).

– APPROXIMATE: Only results that have an approximation.

It is possible to pass multiple location types by delimiting them by a "|" character.

9

Page 14: Google Maps, Skyscanner and eStreaming APIs for collecting

Return Elements Geocoding and reverse geocoding are returning the same elements. The re-sult set contains a <status> element which will be described in section 2.4 and several <results>

elements. Each of the <results> elements contains the following elements:

• address_components: The components of the address.

• formatted_address: The address string of the place.

• geometry: Geometry information about the place.

• place_id: The Google Maps ID of the place.

<address_components> includes the following elements:

• long_name: The name of the place.

• short_name: The abbreviation of the place.

• types: The component type as described for the components parameter.

<geometry> includes the following elements:

• location: The coordinate of the place.

• location_type: The location type of the place as described for the parameter location_type.

A full list of all return elements can be found at [Goog]

2.2.3. Time Zone API

The Google Maps Time Zone API can return time zone information for each place on the earth.After passing a date and a place to the API, it returns the name of the time zone, the daylightsaving time difference and the time zone offset to UTC.

The Google Maps Time Zone API is available at the following URL:

https://maps.googleapis.com/maps/api/timezone/outputFormat?parameters

The output format can have one of the following values:

• json: returns the answer as a json file.

• xml: returns the answer as a XML file.

Available Parameters As parameters a list of the following parameters in arbitrary order canbe used. As the delimiter the "&" char has to be used.

• location: The place from which the time zone should be returned. A latitude and longi-tude separated by a comma. This parameter is required.

• timestamp: A date in epoch time in seconds. This parameter is used for determining theday light saving time. This parameter is required

10

Page 15: Google Maps, Skyscanner and eStreaming APIs for collecting

• key: The API key which is used. This parameter is required

• language: The two letters ISO language code, like "de", "en", "en-AU". This parameter isoptional.

Return Parameters Each result set contains the following parameters:

• dstOffset: The daylight saving time offset in seconds. Returns null if there is no daylightsaving time at the specified time.

• rawOffset: The time difference to the UTC time without daylight saving time offset inseconds.

• timeZoneId: The time zone ID according to the IANA Time Zone Database [IAN]. Usu-ally a country name and a city name.

• timeZoneName: The official name of the time zone.

• status: The status returns OK if it was processed successfully, a status code otherwise. Alist of all status codes can be obtained from [Gooi].

• error_message: Further information about the problem if the status code was not OK.

For determining the UTC time from a local time the calculation is:

localTime - dstOffset - rawOffset

For determining the local time from a given UTC time, the calculation is:

localTime + dstOffset + rawOffset

All values have to be in seconds. Further information about the Google Maps Time Zone APIcan be obtained from [Gooi].

2.3. JavaScript API

This API provides all methods necessary for embedding Google Maps into an HTML page.From displaying the map until drawing markers, lines, figures and text boxes on the displayedmap. In the first section this chapter describes how to embed the Map into a HTML page,followed by descriptions of the most important and for the Trip Planer application used classes.

2.3.1. Initialize Map

The map can be initialized by calling the constructor of the google.maps.Map class. It is neces-sary to pass the HTML container (usually a mapDiv element) in which the new map should becreated and a MapOptions object. For the MapOptions it is required that the center and the zoom

of the map is set. Optionally a lot of other features like max- and minZoom or streetViewControl,which defines if street view should be available on the map or not can be set. An example for

11

Page 16: Google Maps, Skyscanner and eStreaming APIs for collecting

1 map = new google . maps .Map( document . getElementById ( ’map ’ ) , {2 zoom : 4 ,3 c e n t e r : { l a t : 9 ,94792 , lng : 5 1 . 5 5 5 9 4 } ,4 maxZoom : 8 ,5 minZoom : 2 ,6 s treetViewControl : f a l s e ;7 } ) ;

Code Snipped 5: Example for Initialization of a map object

a map initialized in JavaScript can be found in the code snipped 5. A full list of all availableoptions can be obtained from the Google Maps reference page [Goon]. Also it is necessary toinclude the essential libraries from

https://maps.googleapis.com/maps/api/js,

passing the API key and callback the function that includes the upper code snippet. This couldlook like the following code snippet 4:

1 < s c r i p t s r c =" ht tps ://maps . googleapis . com/maps/api/ j s ? key=YOUR\_API\_KEY&c a l l b a c k =initMap " async defer ></ s c r i p t >

Code Snipped 4: Example for including the Java Script library

2.3.2. Classes

The Google Maps Java Script API provides a lot of classes to work with the map. The most im-portant classes which are used for the Trip Planner application will be described in this section.

Map Class Next to the constructor of google.maps.Map which already was described inthe initialize Map section, the Maps class provides a whole bunch of functions. The mostimportant functions will be described below:

fitBounds(bounds:LatLngBounds)

sets the center and the zoom of the map to contain the given bounds.

getBounds()

returns the actual LatLngBounds of the map.

getCenter() setCenter(latlng :LatLng)

returns a LatLng object with the center of the map or sets the center.

getZoom() setZoom(zoom:number)

returns / sets the zoom level of the map. Values between 1 and 20.

getHeading() setHeading(heading:number)

12

Page 17: Google Maps, Skyscanner and eStreaming APIs for collecting

returns / sets the compass heading of the map measured in degrees from north (0 - 360).default is 0.

Also a lot of events such as drag, click, mouseover and many more are available. A list of allavailable functions and events can be obtained at [Goon]

LatLng Class The LatLng class is the base of the most of the operations on a GoogleMaps map. It represents a point on the map using the geographical latitude (lat)and longitude (lng). The latitude reaches from -90 to 90 and the longitude reachesfrom -180 to 180. In JavaScript this object can be generated by using the constructorvar myLatLng = new google.maps.LatLng(−34, 151) or just by generating it with its literalsvar myLatLng = {lat: −34, lng: 151} . In XML, this object is represented by the lat and the lng

tag <lat>−34<\lat><lng>151<\lng> . An array of LatLng objects represents a polyline. If thefirst and the last element of the polyline array are the same coordinate, it represents a closedpolygon. Further information about the LatLng class can be obtained from [Goon].

Marker A Marker is an exact place on the map that is pointed out, by default this is donewith a kind of a red arrow. To initialize a Marker the google.maps.Marker class has to be calledand a MarkerOptions object has to be passed to it. The following properties are related to theMarkerOptions object:

• position: Sets the exact place of the Marker by passing a LatLng object. This property isessential.

• map: Sets the map object on which the Marker should occur.

• animation: Sets a animation object that should play when the Marker is added to the Map.

• clickable: If true, the Marker has click and touch events. The default value is true.

• draggable: If true the user can drag the Marker. The default value is false.

• icon: A string, symbol or icon can be passed that is displayed instead of the red arrow forthe place.

• label: Adds a string or a MarkerLabel object as label to the Marker.

• opacity: A value between 0.0 ad 1.0 that describes the opacity of the Marker

• title: Rollover text of the Marker.

• visible: Boolean if the Marker is visible or not. Default is true.

For all these properties also getters and setters are available. Also a lot of event listeners likeclick, mouseover, position_changed and so on are available. A full list of all methods propertiesand events can be obtained from [Goon].

13

Page 18: Google Maps, Skyscanner and eStreaming APIs for collecting

Polyline Class A Polyline is an array of LatLng objects. Each LatLng object represents onecoordinate. For more information about LatLng objects see section 2.3.2. By connecting thesepoints a line results. These polylines are represented in Google Maps JavaScript by the Polyline

class. The most important functions of this class are:

setPath(Array<LatLng>) getPath()

These methods are used to set the path based on a LatLng array and to get a LatLng arrayrepresenting the path.

setMap(map:Map) getMap()

Specifies the map on which the polyline should be displayed. To remove the polyline from amap, map has to be set to null setMap(null) .

setEditable(editable :boolean) getEditable()

Allows or prohibits the user to edit the polyline.

setOptions(options:PolylineOptions)

Specifies options for the polyline like clickable, icons shown on the line of the polyline,strokeWeight, strokeOpacity, strokeColor and many more. These options can also be set in theconstructor already.

Also a lot of different events like click, mouseover, rightclick and many more for polylines areavailable. A whole list of all available methods, options and events can be found in the GoogleMaps API references [Goon]

LatLngBounds The google.maps.LatLngBounds class is a set of LatLng coordinates whichreturns a rectangular area where all the associated LatLng elements fit in. The LatLngBounds

class can deal with the nontrivial problem if the associated coordinates cross the 180 degreeslongitudinal meridian. The constructor call LatLngBounds(sw?:LatLng, ne?:LatLng) generates anew LatLngBounds object. It is possible to pass the coordinate of the south west corner ad thenorth east corner of the rectangle, but it is not essential. The most important functions for thisclass are:

extend(point:LatLng)

Extends the bounds to include the coordinate.

getCenter()

Returns the center of the LatLngBounds rectangle.

getNorthEast() getSouthWest()

Returns the coordinates of the north east / south west corner of the LatLngBounds rectangle.

contains(latLng:LatLng)

14

Page 19: Google Maps, Skyscanner and eStreaming APIs for collecting

Returns true if the LatLngBounds rectangle includes the passed coordinate.

LatLngBounds have no function to extend the coordinates set by a polyline. In this case it isnecessary to loop through the polyline array and add every single LatLng element.

Symbol The google.maps.Symbol class represents a vector graphic that can be shown on amarker or on a polyline. While using it with markers works pretty well, lots of problems byusing it with polylines do appear. The parameters of Symbol are:

• path / url: The SVG path (just the path not the whole file. The whole graphics can onlyhave one path, no additional circles or lines in this case) or a url to a SVG file or a web urlto a SVG graphic. The url parameter only works for markers but not for polylines. It isrequired to use one of these parameters.

• anchor: Describes the position of the symbol relatively to the marker or polyline. Theanchor can move the symbol up and left by the x and y specified. The anchor expects agoogle.maps.Point object. The constructor is google.maps.Point(x:number, y:number).

• fillColor: The fill color of the symbol.

• rotation: The angle of clockwise rotation of the symbol. In the case of polylines the defaultrotation is the same as the direction of the polyline on this specific point of the symbol.the default rotation for markers is zero.

• scale: Scales the symbol. In case of a polyline the symbol should fit into a square of 22pixels.

• strokeColor: Color of the lines of the graphic.

• strokeOpacity: Opacity of the lines of the graphic.

• strokeWeight: Weight of the lines of the graphic.

Google Maps provides few predefined symboles like arrows and circle atgoogle.maps.SymbolPath.SYMBOL_NAME. SYMBOL_NAME could be CIRCLE or FOR-WARD_OPEN_ARROW for example. A list of all predefined symbols available can be foundat [Goon].In case of a polylines, the symbol can’t be added directly. Instead, an IconSequece object has tobe used, which contains a Symbol. The parameters of the IconSequence object are:

• icon: Icon is the symbol as described above for this object.

• offset: This represents the distance of the symbol from the starting point of the polyline.It can be measured in pixels or in percent.

• repeat: Repeat describes the distance until the symbol repeats on the line. This could bea percentage or a pixel value.

If a line should be dashed a short line has to be used as the symbol and it has to be repeated ina short distance.

15

Page 20: Google Maps, Skyscanner and eStreaming APIs for collecting

Info Window The InfoWindow shows text or picture content on the map. Usually it is used ona marker, but it is also possible to use it on any other arbitrary coordinate. It is common thata info window is used if text or pictures should appear only in certain situations, like a clickor mouse over event. The constructor of the InfoWindow requires a InfoWindowOptions objectwhich will be described next. The InfoWindowOption object has the following parameters:

• open(map?:Map): Opens the InfoWindow on the given map.

• close(): Closes the InfoWindow.

• setContent(content:String) / getContent(): Sets and gets the content. The content is inHTML structure and can be designed with CSS files by using div containers.

• setPosition(position:LatLng) / getPosition(): Sets and gets the position of the InfoWin-

dow. The given coordinate is where the arrow of the InfoWindow points to.

Now, after describing the InfoWindowOptions object, the InfoWindow class can be described. Theconstructor is google.maps.InfoWindow(opts?:InfoWindowOptions). The most important func-tions are:

• content: Sets the content of the InfoWindow. The content is in HTML structure and can bedesigned with CSS files by using div containers.

• maxWidth: Maximum width of the InfoWindow, regardless of the content’s width.

• position: Sets the position of the InfoWindow. The given coordinate is where the arrow ofthe InfoWindow points to.

• pixelOffset: Defines the offset in pixels where the InfoWindow gets displayed, seen fromthe position.

A full list of all parameters, functions and event listeners can be obtained from [Goon] [Goot]

Adding an Info Window to a polyline Addingd an InfoWindow to a Polyline is a little bit morecomplex than adding it to a Marker, because a marker has a single coordinate while a polylinehas a lot of coordinates, which are possible positions of the InfoWindow. Usually it is intendedthat the InfoWindow appears on the position of the polyline where the mouse is located in thatmoment. This can be captured with the mouseover event listener. But then would appear anInfoWindow for every point where the user touches the polyline with the mouse. To preventthis, it is necessary to generate just one InfoWindow object. Because an InfoWindow object canappear only on one position at the same time, on all points touched previously the InfoWindow

will be closed. The last problem is, that the event listener does not know to which polyline thisevent belongs. But, if the InfoWindow should show information which belongs to that polylinethis link is important. The class google.maps.geometry.poly has two methods for checking if acertain point on the map belongs to a poly object:

• containsLocation(point:LatLng, polygon:Polygon): This function checks if the givenpoint lies in the given polygon and returns a boolean.

16

Page 21: Google Maps, Skyscanner and eStreaming APIs for collecting

• isLocationOnEdge(point:LatLng, poly:Polygon|Polyline, tolerance?:number): Thisfunction checks if the given point lies on the given polyline considering the given tol-erance and returns a boolean. A proper tolerance for a polyline is 0.0001 and 0.001.

The following example shows how to implement an InfoWindow on a Polyline which shows datafrom the Polyline object.

1 var infowindow ;2

3 func t ion initMap ( ) {4 [ . . . ]5 infowindow = new google . maps . InfoWindow ( ) ;6 }7

8 polyArray [ i ] . p o l y l i n e . addListener ( ’ mouseover ’ , funct ion ( event ) {9 f o r ( j in polyArray ) {

10 //checks i f the coordinate from the event i s on t h i s p o l y l i n e11 i f ( google . maps . geometry . poly . isLocationOnEdge ( event . latLng , polyArray [ j

] . poly l ine , 0 . 0 0 0 5 ) ) {12 infowindow . setContent ( polyArray [ j ] . summary ) ;13 infowindow . s e t P o s i t i o n ( event . latLng ) ;14 infowindow . open (map) ;15 }16 }17 } ) ;

Code Snipped 6: Example how to implement a InfoWindow on a Polyline.

2.4. Direction API

The Google Maps Direction API is a service from Google that calculates path descriptions be-tween two places considering the given parameters. It returns information about the path,alternatives to the fastest path and a detailed description for navigation [Gooe]. First this chap-ter explains how to do a request and introduces possible parameters and afterwards it explainsthe return elements according to the Google Maps Direction references [Gooe].

2.4.1. Elements of Request

The service is available at the following URL:

https://maps.googleapis.com/maps/api/directions/outputFormat?parameters

The outputformat can have one of the following values:

• json: returns the answer as a json file.

• xml: returns the answer as a XML file

As parameters a list of the following parameters in arbitrary order can be used. As the delimiterthe "&" char has to be used.

17

Page 22: Google Maps, Skyscanner and eStreaming APIs for collecting

Essential Parameters The following parameters have to be passed to the request always:

• origin: Address, coordinates or place ID of the origin place. An address starts with themost detailed element, like the house number and ends with the most general elementlike the country. All spaces have to be replaced by a plus character.

origin=7+Goldschmidt+Straße+Göttingen+Germany

If a coordinate is used the format is first the latitude, followed by a comma, followed bythe longitude without any spaces.

origin=51.555928,9.947877

Place ID’s can be obtained by the Google Maps Geocoding API [Goog] and the Google MapsPlace API [Goou]. To pass them as an origin object "place_id:" has to prepend in front ofthe place ID.

origin=place_id:ChIJx8qYb7jUpEcRMD6slG2sJQQ

• destination: The address, coordinates or place ID of the destination, with the same rulesas described for origin.

• key: An API-key that has to be requested from Google Maps to get access to the GoogleMaps API’s . This key limits the contingent of a user [Gooj].

Optional Parameters The following parameters are optional to pass to a request.

• mode: Sets the means of transportation. Valid values are "driving", "walking", "bicycling"and "transit" (for public transportation). If this parameter is unset the default value isdriving.

• waypoints: Sets an array with waypoints which the route has to pass. Further informa-tion can be obtained from the Google Maps Direction references [Gooe].

• alternatives: If alternatives is set to true the service will return several routes between thegiven origin and destination. The default value is false.

• avoid: This option can pass arguments that should be avoided by calculating the route.Possible values are tolls, highways, ferries and indoor (just for walking).

• language: Sets the language for the return object. The language has to be passed as a twoletters code like "de" for German or "en" for English. Additional two letters can be addedfor regional differences in the language like "en-AU" for Australian English or "en-GB"for British English. Google Maps provides 54 languages. A full list of all language codescan be obtained from [Goos]. If the language is not set, Google will try to find the userslanguage by considering the language settings available in the header of the request, thecountry from the domain and other environmental information available for Google.

18

Page 23: Google Maps, Skyscanner and eStreaming APIs for collecting

• departure_time: Sets the departure time in epoch time seconds (NOT milliseconds). Thevalue has to be an integer. If the departure time is not set, the default value is now (onesecond in the future).

• arrival_time: sets the arrival time in epoch time seconds (NOT milliseconds). This optionis only available in transit mode. It is only possible to set arrival time or departure time,not both together.

An example for the smallest possible request would be to find a path between Göttingen andHannover.

https://maps.googleapis.com/maps/api/directions/xml?origin=Göttingen&destination=Hannover&key=YOUR_API_KEY

In this case, the path is calculated in driving mode and starts one second in the future becausethis is the default behavior. A more enhanced request would be to find a public transportationpath from Göttingen to Hannover with alternative routes on June 12th 2018 at 11:30 AM. Theresponse should be in XML.

https://maps.googleapis.com/maps/api/directions/xml?origin=Göttingen

&destination=Hannover&transportation=transit

&departure_time=1528794000&alternatives=true

&key=YOUR_API_KEY

2.4.2. Return Elements

It doesn’t matter, whether the response is in XML or JSON. In both cases the same elementsare available. The exceptions are, that XML has an additional element that encloses all otherelements named <DirectionResponse> and JSON does not need such an element. Also the re-sponse, if no route could be found is different. JSON returns an empty array for the route

element in this case, while XML returns just no entries for the <route> element. In the followingthe main response elements will be described.

Highest Level

• status: Status returns OK if a valid path was found. Status NOT_FOUND indicates thatone ore more places can’t be found. The status ZERO_RESULTS tells that no route hasbeen found between origin and destination. A list with all error codes can be obtainedfrom [Gooe].

• route: Occurs once if alternatives is set to false, and more than one time if alternatives isset to true. If route has no elements, this indicates that no route was found between theorigin and destination place. Each element represents one route. More about routes lateron.

19

Page 24: Google Maps, Skyscanner and eStreaming APIs for collecting

• geocoded_waypoints: Includes further information about the origin place, destinationplace and the waypoints. For more information consult the geocoded waypoints part ofthe Google Maps Direction API references [Gooe].

Route Each route element contains the elements described in following.

• summary: Consists of a very short text description of the route that allows to distinguishbetween alternative routes.

• leg: Has one entry for every section of the route. If the route has no waypoints, theroute has exactly one leg, otherwise the number of legs of the route equals the numberof waypoints plus one. Detailed information about the elements of leg can be find in thenext part.

• overview_polyline: The overview_polyline consists of an encoded polyline of the route.It is not as detailed as the polylines of the single steps but it is approximately the pathand needs way less memory and transmission rate than the detailed polylines. Furtherinformation about encoded polylines are in the section 2.1.3.

• warnings: Contains elements with warnings for this route.

• fare: Includes the elements currency, value and text, while text is a human readable stringrepresentation of the fare, currency is the currency code according to ISO 4217 and value

is a float number representing the amount of money that the transfer costs in the givecurrency. This information is available only for public transportation if fares are available.It represents the total amount of all tickets necessary on the route.

Legs

• step: A step gives detailed information about each step on the path. Further informationabout the elements of step can be obtained in the next part.

• distance: The distance element consists of a human-readable string representation of thedistance and a value which returns the distance in meters.

• duration: The duration consists of a human-readable string representation of the durationand an integer value representing the duration in seconds.

• duration_in_traffic: Returns a value and text element, following the same rules as for theduration. In this case the duration is calculated by considering the typical and actualtraffic at the specified time. This element is available only if the departure time is set andno waypoints with sojourn are used.

• departure_time / arrival_time: Represents the approximate departure/arrival time. Thiselement is available only in transit mode. It includes the elements value, which con-tains the arrival time as a JavaScript object, text, which contains a human readable string

20

Page 25: Google Maps, Skyscanner and eStreaming APIs for collecting

representation of the time and time_zone which contains the time zone of the destina-tion/arrival stop. The value of time_zone is the name of the time zone according to theIANA-Time-Zone-Database [IAN].

• start_location / end_location: Contains the coordinates (latitude and longitude) of thestart/end location. This can differ from the passed start/end location in the request,because Google Maps sets the start/end location to the next street.

• start_address / end_address: Contains a human-readable string representation of thestart/end address.

Steps A step describes exactly how to come from one to another point and gives furtherinformation about this small part of the route.

• html_instruction: A human-readable HTML instruction how to come to the start pointof the next step.

• distance: The same as the distance element from leg but just for this step.

• duration: The same as the duration element from leg but just for this step.

• start_location / end_location: The coordinates where this step starts/ends.

• polyline: A detailed encoded polyline from the start location of this step to the end loca-tion of this step. For further information about encoded polylines see section 2.1.3.

• transit_details: Gives further information like arrival/departure stop, number of stopsand information about the vehicle in transit mode. A list with all available elements canbe found in the Google Maps Direction API references [Gooe].

A list of all available options and return elements can be obtained from [Gooe]

2.5. Distance API

In contrast to Google Maps Direction, Google Maps Distance just returns the distance and durationto come from one to another place based on the passed parameters and does not return furtherinformation about the route. The benefit by using Google Maps Distance instead of using GoogleMaps Direction is, that Google Maps Distance takes a list of origins and a list of destinations andcalculates the distance and duration between all origin and destination pairs in just one APIcall. Because of the restricted amount of API calls per day is this a huge benefit. Anotherbenefit is that the Google Maps Distance call is faster than the Google Maps Direction call andneeds less transmission rate because the answer is much shorter.The Google Maps Direction API and the Maps Distance API are very similar in most aspects.Therefore this section only explains the differences and changes between Google Maps Directionand Google Maps Distance. To fully understand this section it is essential to study the previoussection first.

21

Page 26: Google Maps, Skyscanner and eStreaming APIs for collecting

2.5.1. Elements of Request

The service is available at the following URL:

https://maps.googleapis.com/maps/api/distancematrix/outputFormat?parameters

The outputformat can have one of the following values:

• json: returns the answer as a json file.

• xml: returns the answer as a XML file

As parameters a list of the following parameters in arbitrary order can be used. As the delimiterthe "&" char has to be used.

Essential Parameters

• origin / destination: One place or a list of places with "|" as the delimiter that is usedas origin/destination places. Every place can be an address, a coordinate or a place IDlike explained in section 2.4. If a list of coordinates is used, it is possible to encode itas a polyline like described in section 2.1.3. In this case the prefix "enc:" has to be usedand a ":" has to be added on the end of the polyline. This is an advantage because of thecharacter limit of the URL which is much smaller by using an encoded polyline insteadof a list of coordinates.

• key: For the key, the same rules apply as for the key in section 2.4.

Optional Parameters Except waypoints and alternatives which do not exist in the Google MapsDistance API all other options follow the same rules as described for the Google Maps DirectionAPI in section 2.4.

2.5.2. Return Elements

In general the same rules apply for the response from Google Maps Distance as for Google MapsDirection. But Google Maps Distance has way less elements and a slight different structure be-cause of the matrix of calculated connections. The enclosing element for the XML fragment ofGoggle Maps Distance is <DistanceMatrixResponse>.

Highest Level The elements of the highest level are,

• status: The value OK means that the request was valid and a response was created. Dif-ferent Error codes describe errors that occurred with the whole query. If a single placecan’t be found, this status can be still OK, a later status will point this out.

• origin_addresses: For every origin there exists one such element which represents theorigin address of one place.

• destination_addresses: For every destination there exists one such element which repre-sents the destination address of one place.

• row: Every row stands for one origin place.

22

Page 27: Google Maps, Skyscanner and eStreaming APIs for collecting

rows Every <Row> represents one origin place and contains one <Element> for every destina-tion place.

Element Each <Element> represents exactly one connection between an origin and a desti-nation. It contains the elements <duration>, <duration_in_traffic>, <distance> and <fare> wherefor all, exact the same rules apply as described for the according element in section 2.4. TheElement

• status: Represents the status of the places and the connections. If it contains OK it means,that all places were found and a connection was returned, if it contains NOT_FOUND itmeans, that the origin or destination place could not be found. If the status containsZERO_RESULT it means that there is no path between the origin and destination place.

23

Page 28: Google Maps, Skyscanner and eStreaming APIs for collecting

3. Skyscanner

Skyscanner is a flight, hotel and car rental search engine. It operates around the globe in over 30different languages and 70 different currencies. Skyscanner tries to connect all travel agenciesand airlines world wide, in order that the users have access to almost all travel offers that areavailable on the market to make the best deal at any time [Skyb]. Skyscanner offers several APIswhich provides different kinds of data. The main APIs are distinguished in three differentfields. The Cached Data APIs provides cached data from previous requests, this data can beaccessed very simple and fast by using GET statements. The Live Price API provides the actualdata about a requested flight and enables a link for booking this flight (This API is currentlynot available [Skyd]). The Place APIs providing static data about places available in Skyscanner[Skya]. A closer view to these APIs will be provided later in this section. APIs for car rentaland hotel search are available as well but woun’t be considered in this report because they areout of topic [Skya].

3.1. API access and restrictions

To get access to the Skyscanner API an account is required. An account can be requestedthroughout the contact form on the home page. The confirmation email includes logging incredentials for Skyscanner, an API key and a portal key. To enable the API key the button Add

App on the Dashboard, which shows up after logging in, has to be used. In the window thatshows up now, all fields have to be filled out. Now the API key is enabled [Skyb].

All request except the requests for the Live Price API have to be done with GET, the Live PriceAPI requests have to be done with POST. To use secure http (https) connections for all requestsis recommended but not essential. The Skyscanner APIs have no daily limit. They are onlyrestricted by requests per minute. The Skyscanner Cache API is restricted to 500 requests aminute, while the Skyscanner Live Price API is restricted to only 100 requests a minute and theSkyscanner Car Hire API is restricted to 100 requests a minute as well [Skyc].

3.2. Place APIs

This APIs provide information about all places that are available in Skyscanner [Skya].

Geo Catalog The Geo Catalog API returns a list of all continents, countries, regions, cities andairports listed on Skyscanner [Skya].

List of Places This is the auto complete API of Skyscanner. A query string with at least 2letters and the country, language and currency of the user has to be passed to the API and a listwith all places that fit the query string will be returned [Skya].

Place Information This API returns information about a specified place. The ID of a place andthe country, currency and language of the user has to be passed to the API. The API will returninformation about the place like the place name and in which higher level places the requested

24

Page 29: Google Maps, Skyscanner and eStreaming APIs for collecting

Figure 2: Valid values for origin and destination [Skya].

place is located. This API also allows to locate the user. By entering the users IP address as theplace ID, the users place will be returned [Skya].

3.3. Cache APIs

The Skyscanner Cached Data API is supplied by data from requests on the Skyscannerhomepage. Skyscanner provides different APIs for different use cases, but in the end there isnothing that could not be done with the Browse Quotes API but with one of the other APIs fromthis section. There is just a difference in the representation of the results that should make itsimpler to work with the received data. The different APIs are described in following [Skya].

All API requests require the origin and destination place, the outbound date, if a return flightshould be returned, the inbound date and the country, currency and language of the user. Butit differs which values the APIs accept for origin, destination, departure date and arrival date[Skya].

Browse Quotes This API returns for any connection that fits the request the lowest price forthe connection. The places can be a specific airport, a city or a country, the destination canalso be anywhere. The date can be a full date, a month or anytime, but it has to be the sametype for both, inbound- and outbound date. The API returns 4 arrays, one for the quotes onefor the places, one for the carriers and one for the currency. The quote array has one entry forevery connection found, that fits the query. If there is one direct and one cheaper connectedconnection on the same route the array will have both entries for this connection. Each quoteentry includes the price, the carrier id, a place id for the origin and destination, the departuredate and the full quote date and time. For every carrier and place id an entry with furtherinformation can be found in the according arrays [Skya].

Browse Routes This API is optimized to get all available routes between the given places orfrom or to anywhere. Both places, origin and destination can be a country or anywhere. Oneof the places, either the origin or the destination can be an airport or city. The date can be aspecific date a month or anytime, but both have to be from the same type. The Browse RoutesAPI returns the quotes, places, carriers and currencies on the same way as described for the

25

Page 30: Google Maps, Skyscanner and eStreaming APIs for collecting

Figure 3: Valid values for inbound and outbound dates [Skya].

Browse Quotes API. As an additional feature this API returns an object Routes as well. Routesincludes an origin id and a destination id, the cheapest price for the route and a link to thequotes found for this route [Skya].

Browse Dates This API is optimized to retrieve the day where the flight for a specified con-nection has the cheapest price. Both places have to be an airport or a city, the inbound- andoutbound date can be a month or anytime. Both dates have to be from the same type. Next tothe quotes, places, carriers and currencies which are already described for the Browse QuotesAPI, this API provides an object for Dates which includes one entry for every month. This ob-ject includes the cheapest price within the month and a list with links to all quote ids whichrepresents flights in that month [Skya]. There also exists a Browse Dates grid API which requiresto use a month as input for outbound- and inbound dates and returns the result in a form thatallows to display it as a calendar very simple [Skya].

3.4. Live Price APIs

The Flights Live Price API is under construction since several months. Skyscanner promises,that the API will be available soon again [Skyd] but it seems as they will have it available justfor business partners in the future. Before, it was possible with a POST request to ask verydetailed for flight information, which returned the exact times of the flight, available seats, andeven direct links to different agencies to book the flight [Skya].

3.5. How to do a Query

The simplest kind of querying the Skyscanner API is to request a one way connection betweentwo places which could be a specific airport or city, a country or even anywhere. The datecould be a specific date a month or anytime. In this example the Browse Quotes API is used andthe origin place should be a specified airport, in this case Munich and the destination place isanywhere to find all connections starting from Munich. As date anytime is used. A request ofthis kind almost guarantees a result. The query url is:

http://partners.api.skyscanner.net/apiservices/browsequotes/v1.0/DE/EUR/de-De/MUC/anywhere/anytime?apiKey=API_KEY

26

Page 31: Google Maps, Skyscanner and eStreaming APIs for collecting

Additionally the parameter Accept with the value xml or json has to be added to the header, todefine in which format the response should be [Skya].

27

Page 32: Google Maps, Skyscanner and eStreaming APIs for collecting

4. eStreaming

eStreaming is an API which provides cached price data from over 10,000,000,000 request daily[eSt]. The eStreaming API belongs to the CEE Travel Systems company which also owns the liveprice travel API Travelport [CEE]. From these servers eStreaming gets once a day all requesteddata for updating its cache [Yulh]. eStreaming provides five different APIs: the Cache API,Historical API, Fly From To API, Fly From API and Flex API [Yuli]. All APIs will be discussed indetail in this section.Originally, IATA codes were intended to describe airports, but in this days IATA codes can alsodescribe train stations or bus stations that are connected to airports in any way. For exampleis it possible to book a flight from Qatar to anywhere in the world while the first part of thetrip is a bus ride from Qatar to the airport in Dubai. Therefore the bus terminal in Qatar got anIATA code. This connections that are not a flight, are really hard to distinguish from the realflights. But Skyscanner’s Geo Location API provides a list of all airports including its IATA code.Therefore all connections found by eStreaming are checked against this database, if one stop ofthis connection is not in the database the connection will not be considered for the result.

4.1. API access and restrictions

For using eStreaming an API key is required. This key can be obtained from [eSt]. After registra-tion, a key will be sent by email. By using a free account the access is restricted to 1000 requestsa day and one request per second. The pricing system of eStreaming is to buy additional re-quests per second. From the first purchased request per second the daily limit is omitted. Eachrequest per second costs between 3.50$ and 5.00$ a day depending on how many requests arepurchased in total [eSt].

4.2. Available APIs

For each API it is essential to select a point of sale for every request. This choice hasto be made because airlines are distributing their flights on different ways and withdifferent fares to different markets [Yuli]. A list with all markets available can be ob-tained from [Yulb]. The point of sale can be passed to the server via the GET parameterpointOfSale. This parameter has to be added to each request. The plain request URL ishttps://api.travelcloudpro.eu/v1/cache/API_NAME?pointOfSale=COUNTRY_CODE&REQUEST

[Yula][Yulg][Yulc][Yuld][Yulf][Yule].

The API response is a JSON file that includes a parameter base64GzippedResponse. This fieldis a JSON file itself, compressed as .gz and encoded as Base 64 [Yulj]. First, this field has to bedecoded. In Java, this can be done with the Base64 class of the Apache Commons Codec library[Liba]. Afterwards the decoded byte stream has to be decompressed. In Java, this can be donewith the standard library java.util.zip.GZIPInputStream [Libb]. A Java method to decode anddecompress this response looks as shown in code snipped 7 [Yulj].

28

Page 33: Google Maps, Skyscanner and eStreaming APIs for collecting

1 import java . u t i l . zip . GZIPInputStream ;2 import org . apache . commons . codec . binary . Base64 ;34 publ ic c l a s s Base64Gzipp {56 publ ic s t a t i c S t r i n g decompress ( S t r i n g base64GzippString ) throws

IOException {7 f i n a l S t r i n g B u i l d e r p la in = new S t r i n g B u i l d e r ( ) ;89 //decode from Base 64

10 byte [ ] compressed = Base64 . decodeBase64 ( base64GzippString ) ;1112 //decompress von gzipp13 f i n a l GZIPInputStream g i s = new GZIPInputStream (new

ByteArrayInputStream ( compressed ) ) ;14 f i n a l BufferedReader bufferedReader = new BufferedReader (new

InputStreamReader ( gis , "UTF−8" ) ) ;1516 re turn bufferedReader . readLine ( ) ;17 }18 }

Code Snipped 7: Base 64 gzipp decoder and decompressor [Liba][Libb]

Cache API This API offers detailed results about an explicit connection between a specifiedorigin and destination airport, based on Travelport shopping requests. A request for this APIrequires a departure date and an origin and destination airport. Optionally a return date canbe added to the request for receiving return flights as well. The JSON response of this re-quest include several connections which includs the origin, destination, fare, carrier, duration,departure- and arrival date and time and flight number [Yula].

Fly From To API This API provides the cheapest price for a return flight with a specifiedstay in a specified time period. The request for this API requires an origin and destinationairport and an earliest possible departure date and a latest possible return date. Optionally theminimum and maximum days of stay can be added to the request. This request returns thelowest possible price for a direct and a connected flight and the departure date [Yule].

Fly From API This API provides the cheapest price for all flights operated from one specifiedairport. The request just requires an origin airport. Optionally a list of destination airports, anearliest and last possible departure date, and the minimum and maximum days of stay can bepassed to the API. The response includes the destination airport, fare, carrier, outbound andinbound date and origin and destination for legs in case of connected flights [Yuld][Yulf].

Flex API This API finds the cheapest flight in a period of plus and minus three days aroundthe departure and arrival date. The API requires an origin and destination airport and aninbound and outbound date. The returned connection can range between plus and minusthree days around the passed inbound and outbound date. The response includes the inboundand outbound dates, the fare and the carrier [Yulc].

29

Page 34: Google Maps, Skyscanner and eStreaming APIs for collecting

Historical API This API allows to pretend to do a Cache API request in the past. The APIrequires a request like that from the Cache API and additionally an earliest search date anda last search date. The API returns cached search results from this given time period. Theresponse contains for every date in the range between the minimal and maximal search date aresult set like described for the Cache API [Yulg].

4.3. How to do a Query

The simplest kind of querying the eStreaming API is to request a one way connection betweentwo airport. The date has to be a specific date. In this example the Cache API is used. The originairport in this example is Munich (MUC) and the destination airport is Hamburg (HAM). Asdate July 14th 2018 (14072018) is used. The URL for this query is:

https://api.travelcloudpro.eu/v1/cache/shopping?searchPhrase=14072018MUCHAM

The API key has to be set in the header by using the parameter AuthToken and setting the valueto the API key [Yula] [Yulj].

30

Page 35: Google Maps, Skyscanner and eStreaming APIs for collecting

5. Trip Planner Application

The Trip Planner application consists of two parts. One part is the server application which iswritten in Java and runs on an Apache Server. The second part is the client application which ismostly written in JavaScript and runs on the client’s web browser. The application has severaldifferent main tasks. The first one is the access to the different APIs. The second one is to createa database with cached flight connections to use them later on for other features. The thirdone is the request handler which consists of different path finding algorithms to find the bestconnection between two given places. The fourth feature is the graphical user interface on theclient application and the last feature is the Connection between the server application and theclient application, using sockets and AJAX.

5.1. Important Objects

Two key objects are widespread used in the server as well as in the client application. The firstone is the Place object which describes a location and the second one is the Connection objectwhich describes any kind of connection. Both are described in detail in the following.

Place object This object represents all kinds of locations throughout the whole application.This object has parameter, getter and setter for the ID and name, which are both of the typeString to be able to hold values like the IATA code of a place, for its coordinate, for the differentaddress values from house number to continent, for the IATA code, in case that the place is anairport, for the language and currency at the place and for the type of the place. The type is aninteger value, two for example represents an airport, six a bus stop, twelve a city and so on.

Connection object The Connection object represents an arbitrary connection between twoplaces, one place is the origin and the other place is the destination. The connection can be aflight, a bus ride, a walk, a drive or any other kind of movement. Which kind of movementis used for this connection is described by the type parameter. Each connection has an action

parameter which can hold the values add and remove. Also, all connections have an ID whichis unique for all connections with the action add and which is the ID of an already existingconnection for all connections where the action parameter holds the value remove. The objecthas also parameters for the departure and arrival time, the duration of this connection and thequote date time for the date and time when the connection was available to this conditions.Furthermore, parameters exist for the price, the carriers, a boolean value that indicates whetherthe connection is direct or not, the weekday of the connections departure, the distance andbeeline distance, the Google Maps Polyline of this connection, an HTML instruction for theconnection, a summary of the connection and a parameter code, which can hold a flightnumber for example. To add a return connection or sub connection, two parameters withlists for Connection objects are available. This lists are realized throughout arrays in theclient application and throughout LinkedBlockingQueues of the type Connection in the serverapplication to ensure thread safe access.

31

Page 36: Google Maps, Skyscanner and eStreaming APIs for collecting

Figure 4: The four levels of Connections.

Every connection is separated into different levels. To access the next level of a connection theparameter subConnection has to be used. Each connection can have up to 4 levels. The highestlevel includes the origin and the destination of the whole connection. The second level splitsthe connection into different parts for every means of transportation. All means of groundpublic transportation are aggregated to one means of transportation in this case. The thirdlevel splits the means of transportation into one connection for each ride. This level splits aconnected flight for example into several direct flights. The fourth level splits the connectioninto very small steps where each step has a detailed route description. This level is mainly usedby Google Maps Direction.For example the Connection from Munich to Hamburg with a plane would be just one Con-nection object for the first level (downtown of Munich to downtown of Hamburg). The secondlevel would split this connection into three parts: The drive from the downtown of Munich tothe airport of Munich, the flight from Munich to Hamburg and the drive from the airport ofHamburg to Hamburg downtown. The third level would now separate the flight connectioninto the single flights if the flight is not direct. For example into the flights from Munich toFrankfurt and from Frankfurt to Hamburg. The fourth level would separate the car connectionto Munich airport and from Hamburg airport into small steps with a detailed route description.See the example in figure 4.

32

Page 37: Google Maps, Skyscanner and eStreaming APIs for collecting

5.2. API Access

APIs from three different companies are implemented in the Trip Planer application. The serverapplication uses APIs from Skyscanner, eStreaming and Google, the client application uses GoogleAPIs only. The use of the APIs in the server application is included in Section 5.5 by describingthe graphical user interface. The methods used to access the APIs in the server application aredescribed in this section.

All classes for API access on the server application are implementing the interface class API

which includes the method getAllConnections that requires an origin and destination place asa string and an outbound and inbound date. While the inbound date can be null, the otherparameters need to hold values. The return type is a LinkedBlockingQueue of the type Con-

nection, which includes one Connection object for each connection that was found for the givenparameters. During the development process it turned out that every API requires very differ-ent input parameters and has very different possibilities. For example can Google Maps distin-guish between different means of transportation [Gooe] while Skyscanner just provides flightconnections [Skya], on the other hand requires Skyscanner and eStreaming a given market place[Skya][Yula] while Google Maps just optionally allows to pass a language [Gooe], but it is notpossible to pass a response language to eStreaming [Yula]. That leads to the problem that it ishard to simplify every API access to such a simple method call. Therefor the classes for access-ing the APIs have own specified methods to call the APIs even so that the access throughoutthe getAllFlights method is possible as well.

5.2.1. Google Maps

The access for each Google API is realized in an own class.

Google Maps Direction API The method getConnection from the GoogleMapsDirection classrequests a one way connection through the Google Maps Direction API. Therefor it is possibleto pass an outbound date and time only and no inbound date and time. The outbound dateand time can be the departure or arrival date and time, the parameter isDepartureDate defineswhich of them is used. This method accepts Place objects instead of strings for the origin anddestination places. The method allows to choose which means of transportation should be usedand which should be avoided, the language can be chosen and whether alternative connectionsshould be returned or not.

Google Maps Distance API The getConnection method for the Google Maps Distance API ispretty similar to the method described for Google Maps Direction. The difference is that a listof Place objects has to be used for the origin and destination place instead of a single Place

object. This is necessary because the Google Maps Distance API calculates the distance betweenmultiple places. Another difference is, that it is not possible to get alternative routes with thisAPI, therefor the method provides no parameter for it.

33

Page 38: Google Maps, Skyscanner and eStreaming APIs for collecting

Google Maps Geolocation API This API is used to add latitude and longitude coordinates toa Place object without coordinates. The method addCoordinatesToPlace expects a Place object,adds the longitude and latitude of the place to it and returns the same object afterwards.

5.2.2. Skyscanner

The constructor of the SkyscannerCache class which includes all methods for the SkyscannerAPI access requires attributes for the country, currency and language of the users market place.All parameters are string values and have to follow the specifications described in Section 3.3for these attributes.

Cache API The method getAllConnections implemented by the API interface uses the BrowseQuotes API described in Section 3.3 to find connections between two airports. If the inbounddate is null, a one way flight will be returned, otherwise a return flight will be returned as well.

Auto Complete The method getAutosuggest uses the List of Places API to return auto comple-tion for a given string of the first characters of a place. The given characters have to be passedas a string to the function. The function returns a list of Place objects including one object foreach place that matches the passed String.

Geo Locations The Geo Location API can be accessed by the method getPlaceList. The methodrequires a string that describes the type of places that should be returned. This can be continent,country, city or airport. The method returns a list with one Place object for each place thatSkyscanner knows of the given type.

5.2.3. eStreaming

The Trip Planner application uses only the Cache API of eStreaming, but there are four differentmethods to request results from it. In the end all four methods use the same API request, thedifference is just how the returned data are processed. The getAllConnections method imple-mented by the API interface expects the origin and destination IATA code as a string and theoutbound and inbound date as a Gregorian Calendar object while the inbound date can still benull. This method returns all direct and connected connections. For the composite connectionsit returns its single parts as sub connections of it. These connections are like direct connectionsbut do not have a price. This method is used for the Cached Flights Connection Database describedin Section 5.3. The method getAllDirectFlights expects only the origin and destination place andthe outbound date but no inbound date. The method returns all flights found between theorigin and destination place for the given date. But it separates the connected flights into itssingle direct flights and returns each of them as an own connection. The getCheapestDirect-

Connection method requires the same input as the getAllConnections method but returns onlythe cheapest direct connection between the origin and destination place. The getCheapestCon-

nection method requires the same input as the getAllConnections method, too. It returns just thecheapest connection that was found between the origin and destination place. It doesn’t matterwhether this is a direct or connected connection.

34

Page 39: Google Maps, Skyscanner and eStreaming APIs for collecting

5.3. Cached Flight Connection Database

Locking up a flight via an API needs a long time, if for one connection a lot of flights have tobe looked up from APIs the time effort would be huge, before a result could be returned. Alsomost of the APIs, especially the flight finding APIs, have a small limit of requests per second,day or even both [Skyc][eSt]. That leads to the need to cache the flight data before they arerequired. The Cached Flight Connection Database stores all flights, including information likethe cheapest price, departure and arrival time and the quote date time. The database alsostores one entry for each airport on the world including its coordinates and IATA code and therelated city. Also one table for all cities that have an airport, all countries and all continents isstored in the database.

The core table of the database is the flight_connections table. The table has columns for theorigin, destination, departure and arrival date and time, duration, quote date time, weekday,price, currency, carrier, flight number and a link to a list with all legs a connection includes.This table has one entry for each flight. Flights can be one of three kinds, direct flights obtainedfrom Skyscanner, direct flights obtained from eStreaming or connected flights. These kindsare distinguishable in the database because all flights received from Skyscanner have no entryfor duration, all other flights have this entry. The direct flights are distinguishable from theconnected ones because the direct flights don’t have a link to a list with all legs while allconnected flights have this link.

For a flight obtained from eStreaming the combination of origin, destination, departure date,arrival date and carrier makes a flight unique. The flight number can’t be used as an identifierfor the same flight because one flight can have different flight numbers if it is offered bydifferent airlines (actual the most flights have several flight numbers) also can the same flightnumber occur every day again. Two direct flights obtained from Skyscanner are identified assimilar if already a flight exists in the database with the same origin and destination for thewhole departure date. For a connected flight the origin, destination and the departure andarrival time indicates that a flight is unique. This doesn’t mean that several flights really arethe same connections if the applications identifies them as similar. For example if a flight hasthree legs and the first and last one are the same but the middle one is different the databasewould deal with this connection like it would be the same one and would just keep the cheaperone. This saves a lot of storage and the path finding algorithm deals with this connection likea direct connection anyway.

The Trip Planner server application has a method to update this database. The first step of thismethod uses the Skyscanner Geo Location API to check if new places are available. In the sec-ond step the Skyscanner Cached Flights API, which finds all outgoing flights from one specifiedairport, is used to check for each airport if there are exists flights that are not in the databasealready. But these flights found by the Skyscanner API have a date and a price but no times andit gives no information about how many times a day this connection is served. Therefor the laststep of the update process is, that all connections available in the database are requested from

35

Page 40: Google Maps, Skyscanner and eStreaming APIs for collecting

the eStreaming API by the getAllConnections method. This API returns detailed informationlike the time and the price for each flight on the connection. Also due to the method chosen forthis request new direct connections that are parts of the requested connected connections areadded to the database.All database update mechanisms are organized modular. That means it is simply possible tochange single steps like finding all flights that an API should request or to change the APIused for the requests just by calling a different method. It is also possible to skip single stepsof the update mechanism. Changing the whole database is even simpler just by changing thedatabase connection information stored in one global class.

Currently the database has entries for 4736 airports on the world whereof 3435 airports areserved. All in all 24748 different direct connections and 7111 different connected connectionsare stored in the database with 408 442 different flights in a time period of six days (up to 46815flights a day). Due to the fact that some connected flights need few days some of the flights areoutside the time period while the "flights a day" value represents how many flights are reallydeparting on one specific day. The queries required to request these values can be found in theappendix A.1.

5.4. Path Finding Methods

The Trip Planner application can use all kinds of path finding algorithms. The path finding isimplemented in the server application. A request has to pass an attribute that tells which al-gorithm to use for the request. Each path finding algorithm has an own class with a methodgetConnectionList. By calling this method and pass the request the method will return a con-nection list with the result of the path finding algorithm. The algorithms can be very easy, forexample just doing an API call with the parameters from the given request or also very complexby doing a lot of API and database calls to calculate an own connection. To add an algorithmto the application, the class of the algorithm has to be added to the pathCalculation package anda method call that calls the getConnectionList method from the added class has to be added tothe RequestHandler class in this package.The already implemented methods are using Google Direction, Google Distance, SkyscannerCache or eStreaming Cache only, as well as one method that combines database entries, GoogleMaps Direction and eStreaming Cache on a simple and trivial way. This method is named FindFirst Connection and is described in this section right after a short description of the first fourmethods.

Both methods for the Google Maps APIs using the coordinates of the requested origin and desti-nation place and query the API with these values. They simply return the results. The Skyscan-ner and eStreaming methods query the database for the closest airport (beeline) for the originand destination place and query afterwards the according API for a connection between theseboth airports. if no connection can be found between these airports an empty connection listwill be returned.The Find First Connection method is a combination that uses the airports table of the Trip Planner

36

Page 41: Google Maps, Skyscanner and eStreaming APIs for collecting

Figure 5: Input box of the Trip Planner user interface.

database, the Google Maps Direction API and the eStreaming Cache API. In the first step it queriesthe database for the ten nearest airports to the origin place and to the destination place usingthe beeline distance calculated by the database. The next step requests for each airport foundthe distance to the corresponding origin or destination place by using Google Maps Direction.For the calculation it is possible to choose one of the available means of transportation fromGoogle Maps. Now the airports are ordered by the duration or the distance to the origin ordestination place. In the last step the algorithm calculates which airport has to be used that thesum of the way from the origin place to the origin airport and from the destination airport to thedestination place is as small as possible but a connection is available. As soon as a connectionwas found the method returns this connection, if after considering all ten origin airports andall ten destination airports no connection was found the method returns an empty connectionlist. In the worst case scenario this method needs 100 API calls for one connection.

5.5. Graphical User Interface

The task of the Trip planner client application is to provide the user interface. This applicationshould allow the user to insert a request comfortably and to get the result displayed in a niceand clear way. The functions of the client application therefor are limited to functions forvalidating the user input, generating a request for the server, connecting to the server andprocessing the response from the server application to display it for the user. The user interfacehas three different parts. The first part is the input window, the second part is the map and thelast part is the text output with detailed information about the journey.

Input Window The input window, shown in Figure 5, allows the user to insert the origin anddestination place. These fields dispose over a Google auto complete function which completesthe place name as well as adding coordinates to it. This function makes a place used for therequest unique. Also the inbound and outbound date can be chosen from a calendar withvalid date and time values. Later on it is possible to choose whether the given date and timeshould be the departure or arrival time. The next box allows the user to choose which meansof transportation should be considered by calculating the path. Car, public transport, walk,bicycle and airplane are possible selections.The last box provides further options about the calculation algorithm and how to display theresult. The first option lets the user choose one of the available path calculation algorithms, thenext option lets the user select whether the given inbound and outbound date is the departure

37

Page 42: Google Maps, Skyscanner and eStreaming APIs for collecting

Figure 6: The map shown on the user interface of the Trip Planner application.

or arrival date and time. The third option selects whether each sub connection should get a newcolor or just each alternative connection should get a new color on the map. With the fourthoption it is possible to use a predefined example. This allows the user to define an example anduse it all the time instead of inserting all input fields lot of times for test purposes. The Leveldefines how detailed the lines and the text output should be. If the level is one it will just be aline drawn between the origin and the destination place, if the level is four, for each corner willbe described how to proceed. The next option selects if just the result of the used algorithmshould be shown on the map and the text output (plain connection) or if all connections thatthe algorithm was using to calculate the connection should be shown on the map and the textoutput. In this case all unused connections are displayed in grey. Pushing the green Go. buttonrequests the result.

Map The map displays the path of all connections found for a request or even all connectionsused to calculate the path by the path finding algorithms. See Figure 6 for an example. Allpaths that have been used for the calculation, but that are not part of the result connections,are displayed in grey. All other paths have different colors for each step or for each connection,depending on the previous selections. If the user follows the path with his cursor further infor-mation like the means of transportation, stops or the flight number of a flight occurs in an infowindow on the path.

Text Output The text output of the Trip Planner user interface provides detailed informationabout the trip and its single steps. How detailed the output is depends on the selected optionsin the input window. If detail level four is selected the text output provides detailed navigationinformation. If lower detail levels are selected the output provides less steps like just one foreach means of transportation. For further information about the different levels see Section5.1. Each step displayed in the text output can provide several information like the origin anddestination, the departure and arrival date, the duration, a price, the means of transportationand a lot more. Each higher level summarizes all levels below. Figure 7 shows a part of the textoutput.

38

Page 43: Google Maps, Skyscanner and eStreaming APIs for collecting

Figure 7: A part of the text output of a connection on the user interface of the Trip Plannerapplication.

5.6. Communication between Server and Client

The request is entered by the user in the user interface running on his own computer inJavaScript. But the path calculation is done by a Java application running on the server. Thatmeans, that the request has to be transmitted from the user’s computer to the server and theresult the other way around. That is not at least because of security reasons a non-trivial task.The Trip Planner application realizes the communication in two steps. In the first step theJavaScript part of the client application which is running on the client computer calls a PHPscript from the client application which is running on the server and sends the request encodedas JSON to the server machine. For this call AJAX is used. The second step is that the PHPscript calls a socket of the server application which runs in Java on the same machine as thePHP script. The third step is that the request is converted from its JSON format to a Java object.After calculating the path the result is send back to the client the other way around. The firststep converts the Java Connection object into the JSON format. Then the socket sends the JSONfile back to the PHP script running on the same machine and the third step is that the PHPscript forwards the response to the client which encodes the JSON to a JavaScript object. Figure8 illustrates the connection process.A problem with using JSON is that JSON can not handle date and time objects. Instead of aJavaScript date object the departure, arrival and quote date time returned in an object withvalues for the year, month, date and so on and the duration is returned just as a millisecondsvalue. Therefor it is necessary to go through all this objects and convert them manually to aJavaScript date object after converting the JSON file to JavaScript objects.

39

Page 44: Google Maps, Skyscanner and eStreaming APIs for collecting

Figure 8: Communication between the client application and the server application.

6. Conclusion and Further Research

Several different APIs are available on the market to get travel data for flights [eSt] [Skyb] andother means of transportation [Gooe] [Goof]. The most of these companies offers only theircached data for free and charges for the live price data. The free offered cached APIs are alsorestricted to a quiet small limit of accesses per day, second or even both. The different APIsprovides very different kinds of data. Some APIs provides more data others provides less data.That leads to the problem that in an own cached database (like the Cached Flight Database

of the Trip Planner Application) which is filled up with data from different APIs some entrieshave other values than other ones. Also it is a problem, that the data is never be completeand up to date for the same reason. One more problem by accessing API data is that the syn-tax of the APIs is changing permanently which leads to an ongoing high effort for maintenance.

However in the end it was possible to create a database for storing flight data received fromthe Skyscanner and eStreaming APIs which is growing with every day. Also the API accessto Google Maps APIs was implemented to find the best reachable airports from each point onthe world by using a car or public transport. Also efficient methods to access these data forcalculating flight paths and simple path finding algorithms for flights was implemented.

Now, it is possible to develop more complex path finding algorithms for flights in a furtherresearch. These algorithms can use the cached flight database and the API accesses as a datasource. Also some functions implemented in the Trip Planner Application can be used for morecomplex path calculation. Another research field could be how to get more data and how toguess missing data as good as possible by combining already available data.

40

Page 45: Google Maps, Skyscanner and eStreaming APIs for collecting

List of Figures

1. Google API Dashboard. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42. Valid values for origin and destination [Skya]. . . . . . . . . . . . . . . . . . . . . 253. Valid values for inbound and outbound dates [Skya]. . . . . . . . . . . . . . . . . 264. The four levels of Connections. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325. Input box of the Trip Planner user interface. . . . . . . . . . . . . . . . . . . . . . . 376. The map shown on the user interface of the Trip Planner application. . . . . . . . 387. A part of the text output of a connection on the user interface of the Trip Planner

application. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398. Communication between the client application and the server application. . . . . 40

41

Page 46: Google Maps, Skyscanner and eStreaming APIs for collecting

References

[CEE] CEE. CEE Travel Systems. Available at http://www.cee-systems.com/, keywords =Apollo;Galileo;software;travel agencies;Travelport.

[eSt] eStreaming. eStreaming API home page. Avail-able at http://estrapi.cee-systems.com/?gclid=Cj0KCQiA_5_

QBRC9ARIsADVww15XXTTeljjr59Q-vCgXk5Xa6VibKm3fkx9bgZwqRY25QqQ7J1V08hcaArAlEALw_

wcB.

[Gooa] Google. Algorithmusformat für codierte Polylinien | Google Maps APIs | GoogleDevelopers. Available at https://developers.google.com/maps/documentation/

utilities/polylinealgorithm.

[Goob] Google. Autocomplete für Adressen und Suchbegriffe | Google Maps JavaScriptAPI | Google Developers. Available at https://developers.google.com/maps/

documentation/javascript/places-autocomplete.

[Gooc] Google. Die Google Maps Geolocation API | Google Maps Geolocation API | GoogleDevelopers. Available at https://developers.google.com/maps/documentation/

geolocation/intro.

[Good] Google. Einführung in Google Maps Roads API | Google Maps Roads API | GoogleDevelopers. Available at https://developers.google.com/maps/documentation/

roads/intro.

[Gooe] Google. Entwickler-Leitfaden | Google Maps Directions API | Google Develop-ers. Available at https://developers.google.com/maps/documentation/directions/intro?hl=de.

[Goof] Google. Entwickler-Leitfaden | Google Maps Distance Matrix API | GoogleDevelopers. Available at https://developers.google.com/maps/documentation/

distance-matrix/intro.

[Goog] Google. Entwickler-Leitfaden | Google Maps Geocoding API | Google Develop-ers. Available at https://developers.google.com/maps/documentation/geocoding/

intro#ComponentFiltering.

[Gooh] Google. Erste Schritte | Google Maps Elevation API | Google Developers. Availableat https://developers.google.com/maps/documentation/elevation/start.

[Gooi] Google. Erste Schritte | Google Maps Time Zone API | Google Developers. Availableat https://developers.google.com/maps/documentation/timezone/start.

[Gooj] Google. Get a Key/Authentication | Google Maps Directions API | Google Develop-ers. Available at https://developers.google.com/maps/documentation/directions/get-api-key.

[Gook] Google. Get a Key/Authentication | Google Maps Geocoding API | GoogleDevelopers. Available at https://developers.google.com/maps/documentation/

geocoding/get-api-key.

[Gool] Google. Google Maps APIs for Web | Google Developers. Available at https://developers.google.com/maps/web/.

[Goom] Google. Google Maps Embed API | Google Developers. Available at https://

developers.google.com/maps/documentation/embed/.

42

Page 47: Google Maps, Skyscanner and eStreaming APIs for collecting

[Goon] Google. Google Maps JavaScript API V3 Reference. Available at https://developers.google.com/maps/documentation/javascript/reference.

[Gooo] Google. Google Maps Web Service APIs | Google Developers. Available at https://developers.google.com/maps/web-services/.

[Goop] Google. Google Places API Web Service | Google Developers. Available at https://developers.google.com/places/web-service/.

[Gooq] Google. Google Static Maps API | Google Developers. Available at https://

developers.google.com/maps/documentation/static-maps/.

[Goor] Google. Google Street View Image API | Google Developers. Available at https://developers.google.com/maps/documentation/streetview/.

[Goos] Google. Häufig gestellte Fragen (FAQ) | Google Maps APIs | Google Developers.Available at https://developers.google.com/maps/faq?hl=de#languagesupport.

[Goot] Google. Info-Fenster | Google Maps JavaScript API | Google Developers. Availableat https://developers.google.com/maps/documentation/javascript/infowindows.

[Goou] Google. Places-Bibliothek | Google Maps JavaScript API | Google Develop-ers. Available at https://developers.google.com/maps/documentation/javascript/places#place_details_results.

[Goov] Google. Preise und Nutzungsmodelle | Preise und Nutzungsmodelle für GoogleMaps APIs | Google Developers. Available at https://developers.google.com/maps/pricing-and-plans/.

[IAN] IANA. IANA — Time Zone Database. Available at http://www.iana.org/time-zones.

[IAT] IATA. IATA - IOSA Registry. Available at http://www.iata.org/whatwedo/safety/

audit/iosa/Pages/registry.aspx.

[ITA] ITA Software by Google. ITA Software by Google. Available at http://www.

itasoftware.com/.

[Liba] Base64 (Apache Commons Codec 1.11 API). Available at https://commons.apache.org/proper/commons-codec/apidocs/index.html.

[Libb] GZIPInputStream (Java Platform SE 7 ). Available at https://docs.oracle.com/

javase/7/docs/api/java/util/zip/GZIPInputStream.html.

[Skya] Skyscanner. API Reference. Available at https://skyscanner.github.io/slate/

#geo-catalog.

[Skyb] Skyscanner. Skyscanner - Discover Skyscanner. Available at https://www.skyscanner.net/aboutskyscanner.aspx.

[Skyc] Skyscanner. Which services can I access and what are the rate limits?Available at https://support.business.skyscanner.net/hc/en-us/articles/

206800359-Which-services-can-I-access-and-what-are-the-rate-limits-.

[Skyd] Skyscanner. Why do I get an error when accessing the Flights Live Pricing API?Available at https://support.business.skyscanner.net/hc/en-us/articles/

212682245-Why-do-I-get-an-error-when-accessing-the-Flights-Live-Pricing-API-.

43

Page 48: Google Maps, Skyscanner and eStreaming APIs for collecting

[Yula] YulianaGoncharenko. Cache API · CEE eStreaming API. Available at https://docs.travelcloudpro.eu/cached-api.html.

[Yulb] YulianaGoncharenko. FAQ · CEE eStreaming API. Available at https://docs.

travelcloudpro.eu/faq.html.

[Yulc] YulianaGoncharenko. Flex API · CEE eStreaming API. Available at https://docs.travelcloudpro.eu/flex-api.html.

[Yuld] YulianaGoncharenko. Fly From API · CEE eStreaming API. Available at https://docs.travelcloudpro.eu/fly-from-api.html.

[Yule] YulianaGoncharenko. Fly From To API · CEE eStreaming API. Available at https://docs.travelcloudpro.eu/fly-from-to-api.html.

[Yulf] YulianaGoncharenko. Fly From with options API · CEE eStreaming API. Available athttps://docs.travelcloudpro.eu/fly-from-with-options.html.

[Yulg] YulianaGoncharenko. Historical API · CEE eStreaming API. Available at https://docs.travelcloudpro.eu/historical-api.html.

[Yulh] YulianaGoncharenko. Introduction to eStreaming API · CEE eStreaming API. Avail-able at https://docs.travelcloudpro.eu/.

[Yuli] YulianaGoncharenko. Point Of Sale · CEE eStreaming API. Available at https://docs.travelcloudpro.eu/pointofsale.html.

[Yulj] YulianaGoncharenko. Using Postman Application · CEE eStreaming API. Available athttps://docs.travelcloudpro.eu/using-postman-application.html.

44

Page 49: Google Maps, Skyscanner and eStreaming APIs for collecting

A. Appendix

A.1. Statistic Queries

Queries to the cached flights database, to give statistical information about the stored data.

A.1.1. All Airport

Returns all airports listed in the database.

1 SELECT *2 FROM a i r p o r t s ;

A.1.2. All served Airport

Returns all served airports listed in the database.

1 SELECT DISITINCT o r i g i n2 FROM f l i g h t _ c o n n e c t i o n s ;

A.1.3. Different direct connections

Returns all different direct connections in a certain time period listed in the database.

1 SELECT DISITINCT or ig in , d e s t i n a t i o n2 FROM f l i g h t _ c o n n e c t i o n s3 WHERE connection_number IS NULL4 AND departure_date BETWEEN ’ 2018−04−05 0 0 : 0 0 : 0 0 ’ : : timestamp AND ’ 2018−04−18

2 3 : 5 9 : 0 0 ’ : : timestamp ;

A.1.4. Different connected connections

Returns all different connected connections in a certain time period listed in the database.

1 SELECT DISITINCT or ig in , d e s t i n a t i o n2 FROM f l i g h t _ c o n n e c t i o n s3 WHERE connection_number IS NOT NULL4 AND departure_date BETWEEN ’ 2018−04−05 0 0 : 0 0 : 0 0 ’ : : timestamp AND ’ 2018−04−18

2 3 : 5 9 : 0 0 ’ : : timestamp ;

A.1.5. Total flightsflights all in all in time periode

Returns all served airports listed in the database.

1 SELECT or ig in , d e s t i n a t i o n2 FROM f l i g h t _ c o n n e c t i o n s3 WHERE connection_number IS NULL4 AND departure_date BETWEEN ’ 2018−04−05 0 0 : 0 0 : 0 0 ’ : : timestamp AND ’ 2018−04−18

2 3 : 5 9 : 0 0 ’ : : timestamp ;

I

Page 50: Google Maps, Skyscanner and eStreaming APIs for collecting

A.1.6. Amount of flights

Returns for each day on the defined time periode the amount of flights listed in the database.

1 SELECT departure_date , count ( departure_date )2 FROM (3 SELECT or ig in , d e s t i n a t i o n , connection_number , CAST(CAST( departure_date

AS date ) AS timestamp ) AS departure_date4 FROM f l i g h t _ c o n n e c t i o n s ) AS connect ions5 WHERE departure_date BETWEEN ’ 2018−04−05 0 0 : 0 0 : 0 0 ’ : : timestamp AND ’

2018−04−18 2 3 : 5 9 : 0 0 ’ : : timestamp6 AND connection_number IS NULL7 GROUP BY departure_date ;

II