**5. Case Study**

This section presents a case study where the proposed multi-level algorithm approach is applied to solve the cruise tourist problem in the metropolitan port city of Bari. Bari is the capital city of Apulia Region and the second biggest city in southern Italy. Since the roman epoch, Bari became an important commercial center, during the Saracen domination. From 1071, it became a big maritime center and still today it is an important port hub of the Mediterranean sea.

In the initialization phase of Algorithm 1, all the main attractions of Bari are determined and represented by the adjacency matrix of the graph *Gi* as it shown in Figure 10. Note that the weight of arcs are decided on the basis of the time preference (a) described in Section 3, according to the user. For better understanding of Figure 10 let us consider two examples: "1mp" in the box from PoI 2 to PoI 1 means that the tourist should travel by foot for 1 min; "10m p+a" in the box from PoI 2 to PoI 7 means that the tourist should travel by foot and by bus for 7 min total. The tourist inputs are provided in the initialization phase of

the mobile application, where the tourist inserts the preferences and constraints related to: (i) the maximum available time for the outward and return path; (ii) the PoIs to visit during the outward and return path; (iii) the preferred transport mode, i.e., by foot, by bus or the fastest way (see Figure 11). Moreover for each node of the PoI network, the tourist can edit the selection of transport mode according to his/her preferences (see Figure 12).

Let the Saint Nicolas Basilica (node 2) be the starting point and Lungomare Nazario Sauro (node 8) be the final point of the tourist itinerary. Note that for path *Po* the starting point is node 2 and the final point is node 8. On the contrary, for *Pr* the starting point is node 8 and the final point is node 2. In particular, let us define the nodes of priority level 1 (maximum priority) *Vp* = {1, 2, 4, 5, 8, 9, <sup>10</sup>}, and the secondary nodes with *Vs* = {3, 6, <sup>7</sup>}. Furthermore, the PoI to be visited on the outward and return paths and the stop time at each PoI are also reported in Figures 10 and 13.


**Figure 10.** Adjacency matrix of graph *Gi*.

**Figure 11.** The GUI of the user preferences.

**Figure 12.** The GUI showing the travel times in the PoIs network from museo Nicolaiano. Preferred transport mode can be edit.


**Figure 13.** Stop time at each PoI.

The Algorithm 1 creates the two graphs *Go* and *Gr* by using only the nodes of *Gi* of priority level 1 (maximum priority) and calculates the travel times *t*1 and *t*2, as it is reported in Figure 14. It implies *Vo* = {1, 2, 4, 5, 8} and *Vr* = {2, 8, 9, <sup>10</sup>}. The travel times *t*1 and *t*2 do not include the time needed to go from the port to the first stop of the tour, i.e., node 2, and vice versa that is equal to 10 min. In Figure 15 the vector of the times to reach the port from each node is shown.

**Figure 14.** The Graphs *Go* and *Gr* and the travel times *t*1 and *t*2.


**Figure 15.** Travel times from each node of *Gi* to the port.

Let us set *to* = 150 min and *tr* = 250 min. Since *t* > 0, as *t*1 = 159 (obtained by the sum of the travel and stop times from one node to another in the outward path, except the stop times of node 2 and 8) and *t*2 = 189 (obtained by the sum of the travel and stop times from one node to another in the return path, considering also the stop times of node 2 and 8), this solution is not feasible.

Therefore, Algorithm 1 goes to Algorithm 1.1 that tries to exchange the nodes between graph *Go* and *Gr* in order to obtain all the feasible solutions that are stored in *FS*. In the table FS, two solutions are stored which are obtained by the following two nodes exchanging: (i) node 4 of *Go* with node 10 of *Gr*, (ii) node 1 of *Go* with node 10 of *Gr*. In Figure 16, *Po* and *Pr* of solution (i) obtained by solving ILP1 are shown. In this case *t* < 0 and *t* < 0, since *t*1 = 130 and *t*2 = 212 (node 2 and 8 are visited during the return path).

**Figure 16.** Algorithm 1.1 exchanges node 4 of *Go* with node 10 of *Gr*

In Figure 17, *Po* and *Pr* of solution (ii) obtained by solving ILP1 are shown. In particular, in this case *t* < 0 and *t* < 0, since *t*1 = 129 (node 2 and 8 are visited during the outward path) and *t*2= 215.

$$\begin{array}{cccc} \textbf{Po}: & \widehat{\textbf{(2)}} \xrightarrow{\textbf{6}\ \textbf{m}} & \textbf{(4)} \xrightarrow{\textbf{6}\ \textbf{m}} & \textbf{(5)} \xrightarrow{\textbf{10}\ \textbf{m}} & \textbf{(6)} \xrightarrow{\textbf{10}\ \textbf{m}} & \textbf{(7)}\\ & & \textbf{30 min.} & \textbf{50 min.} & \textbf{10 min.} & \textbf{40 min.} \\\\ \textbf{Pr}: & \widehat{\textbf{(8)}} \xrightarrow{\textbf{10}\ \textbf{m}} & \textbf{(9)} \xrightarrow{\textbf{11}\ \textbf{m}} & \textbf{(1)} \xrightarrow{\textbf{12}\ \textbf{m}} & \textbf{(2)} & \textbf{(10) min.} \\\\ & & & \textbf{60 min.} & \textbf{60 min.} & \textbf{30 min.} \\ \end{array}$$

**Figure 17.** Algorithm 1.1 exchanges node 1 of *Go* with node 10 of *Gr*

The two resulting feasible solutions are shown to the user that can select the preferred one in the mobile application (see Figure 18). Let us suppose that the tourist selects path (i). Therefore, Algorithm 1.1 goes to Algorithm 1.3 that tries to add nodes of priority 2 both on the outward and on the return paths. Since it implies that *t* > 0, node 3 cannot be added to the route and it is removed. The adding of node 3 is checked for the outward path (see Figure 19). In this case, there is time available since *t* < 0 and *t*2 = 244. Therefore, node 3 with priority 2 is added to *Gr*. Moreover, since there are no other nodes of *Gi* to be added, the outward journey does not change.

**Figure 18.** The GUI of the feasible solutions.

**Figure 19.** The outward path after adding node 3 to *Gr*.

Figures 20 and 21 depicts the GUI of the mobile application showing the final outward and return paths, respectively, connecting the identified PoIs.

**Figure 20.** The GUI of the outward path.

**Figure 21.** The GUI of the return path.

The procedure ends and the tourist can ge<sup>t</sup> the sequence of attractions in both trips with the relative means of transport. In the proposed case study, the mathematical calculations to obtain the final solution are performed in about 2 seconds.

The presented application demonstrates the effectiveness of the proposed heuristic approach in planning the itinerary for the one-day tourist, customizing the outward and return paths of the roundtrip in the city of Bari. In particular, the application can manage the map of city PoIs, showing the travel means and times for each PoI pair, decided based on the user preferences. The tourist preferences can initially be input through specific app pages like presented in Figures 11 and 12, where it is possible to decide which PoIs to be visited in the outward and return paths, respectively, and the preferred traveling mode. In particular, in the proposed case study it is evident how the Algorithm 1.1 recovers the initial unfeasible solution providing to the tourist alternative feasible trips including all the high priority PoIs. After the user choice, made as in the app page in Figure 20, Algorithm 1.3 further improves the solution adding node 3 belonging to secondary priority list, given one more PoI to be visited.

Let us remark that the obtained solution by applying the proposed procedure can be sub-optimal because of the human intervention. Indeed, with respect to a classical orienteering problem, the user subdivides the PoIs between outward and return trip and can choose a feasible itinerary according to the preferences affecting the real time procedure. Nevertheless, even if the obtained solution can be non optimal, it is surely customized based on the user preferences. Moreover, in Section 4, we enlighten that the proposed heuristic procedure shows better performances than other algorithms such as D-algorithm and S-algorithm [49] in some specific cases.
