When searching for ights, current systems often suggest routes involving waiting times at stopovers. There might exist alternative routes which are more attractive from a touristic perspective because their duration is not necessarily much longer while o ering enough time in an appropriate place. Choosing among such alternatives requires additional planning e orts to make sure that e.g. points of interest can conveniently be reached in the allowed time frame. We present a system that automatically computes smart trip alternatives between any two cities. To do so, it searches points of interest in large semantic datasets considering the set of accessible areas around each possible layover. It then elects feasible alternatives and displays their di erences with respect to the default trip.
Our system leverages the increasing availability of open city transportation
data (in e.g. the General Transit Feed Speci cation (gtfs) [
The global architecture of our system is shown in Figure 1. It consists of a
lightweight client-side part in which users indicate a city of origin and a city of
destination and which also displays results, and a backend part with an entry
point called master. As shown in Figure 1, the master executes three di erent
processes A,B and C. Process A corresponds to a usual ight nder: it returns
trips sorted by simple criteria such as the number of connections and the transit
time (by default). Process C queries the Open Street Map (osm) [
To obtain smart trip alternatives for a transit between two airports A1 and A2, process B performs reasoning on aggregated data coming from various sources thanks to the four sub-processes B1, B2, B3, and B4 (Figure 1). The analyzer rst queries the ight nder (B1) to gather possible paths (without cycles) taking o from A1 and landing at A2. Then, it applies lters to this set of paths according to two customizable usecases: (1) it keeps paths having at most a X-hour connection; (2) it only considers paths having at least a connection longer than Y hours; where X and Y are user-de ned. Moreover, it always tries to avoid connections requiring to spend one night in a hotel somewhere on Earth and rather promotes night in aircrafts, by default. Knowing the possible connections, the analyzer asks the gtfs store (B2) to nd among the city transit datasets all the accessible areas from each intermediate airport. This concept of accessibility depends on the usecase i.e. the gtfs store only considers areas from which one can go and return in less than M minutes, where M is equal to the minimum between one quarter of the connection time and 2 hours. A set of accessible stations (using public transport) is hence available for each possible connection. To enrich user experience, the analyzer rst seeks points of interest (pois) in these areas using sparql queries evaluated on DBpedia4, and then further queries other rdf databases for semantic enrichment (B3), e.g. with local restaurants. Then, in (B4) the analyzer fetches ranks and reviews of other users concerning all accessible pois. All these considerations are used to obtain an overall score for each area; the analyzer can thereby choose among the best retained ones using a (customizable) score function. 2 http://spark.apache.org 3 For example, gtfs data for the Los Angeles city area represent 20GB (due to seventy million direct paths between all regional stations). 4 http://dbpedia.org The typical scenario consists in using our processing pipeline in order to obtain smart trip alternatives using various data sources: gtfs schedules, osm tiles and DBpedia rdf data. One interest of such a tool relies on the fact that users can nd alternatives using real data e.g. the scheduling grids are the ones used each day by o cial transit agencies and semantic data comes from DBpedia. For instance it is possible to review suggestions of trip alternatives to come to the conference. Users can search for trip alternatives passing as argument two airports and two allowed time lapses for connections. For instance, from Paris in France (CDG) to Honolulu in Hawaii USA (HNL) allowing 3 to 5 hours and more than 8 hours, the pipeline (Figure 1) might propose at rst to pass through San Francisco CA (as a conventional \fastest trip nder") since it is the fastest trip available. Then, it considers e.g. the Naritasan Shinsho-ji Temple (20 min. far from Tokyo) and also Venice Beach (40 min. far from Los Angeles). 4
There exists many trip planning systems such as Google Maps and Rome2Rio.
These systems allow to obtain routes that satisfy simple criteria such as shortest
path, shortest duration, cheapest price, and combinations of them. Compared to
these systems, we bring an additional semantic layer that allows our system to
suggest smart alternatives, e.g. alternatives that do not necessarily satisfy the
initial criteria entered by the user, but that will be preferred in the end. Closest to
our approach are the works on automatic construction of travel itineraries [