Design and Implementation of a Daily Activity Scheduler in the Context of a Personal Travel Information System

Abstract

How to effectively schedule individual’s daily activities in actual temporal–spatial environments is a challenging task especially when considering various dynamic conditions and constraints. In this chapter, we present a prototype of a personal daily activity scheduler based on our previously developed travel information system, where point of interest (POI) information and travel information have been integrated into an individual’s agenda service. The scheduler provides all operations based on constraints checking, agenda operations (e.g., inserting, updating and deleting activities), recommending locations, detecting deviations from schedule, detecting real-time event consequences and detecting relevant POIs. Initial tests for the basic operations indicate that the approach works well and more comprehensive tests will be conducted in the future.

Appendix

1.1 Basic Calendar Operations

1.1.1 Insert

We tested four cases for the insert operation: insert an activity in an empty agenda; insert an activity where there is an activity after the insert activity; insert an activity where there is an activity before the insert activity, and insert an activity where there are activities before and after the insert activity.

In the first case, we insert an activity into an empty agenda (Fig. A.1 in appendix). The activity is specified as (1, “Work”, 2011-10-05 09:15:00, 2011-10-05 11:45:00, “Naples”, 14.279, 40.864, “Boss, Tom and Lucy”, “project progress”). We receive a ‘correct’ response and the item can be found in the server’s data table (Fig. A.2 in appendix).

Fig. A.1

Insert-I

Fig. A.2

Insert-II

In the second case, there is already one item in the agenda. The new activity is specified as: (1, “Breakfast”, 2011-10-05 07:00:00, 2011-10-05 07:30:00, “Naples”, 14.222, 40.85, “”, “”) which is earlier than the previously inserted activity. A trip needs to be inserted as the new insert activity has a different location than the later activity. A trip request to the routing system is specified as: (1, “foot, bus, train”, 2011-10-05 07:30:00, “departure”, “MinmalTimeCost”, “Naples”, 14.222, 40.85, “Naples”, 14.279, 40.864). The routing system suggests departure at 07:33:21 and estimates arrival at 08:26:47. The detailed schedule for the trip is stored in the table which may involve several transfers and which the user can use as a route plan for public transport. The travel information can be retrieved and displayed for the user through the standard interface. We receive a ‘correct’ response from the scheduler and the item can be found in the server’s data table (Fig. A.3 in appendix).

Fig. A.3

Insert-III

In the third case, we insert a next new activity specified as: (1, “Work”, 2011-10-05 15:30:00, 2011-10-05 16:30:00, “Naples”, 14.34, 40.84, “”, “”) which is later than the activity inserted in the first case. A trip needs to be inserted as the new insert activity has a different location than the earlier activity. A trip request to the routing system is specified as (1, “foot, bus, train”, 2011-10-05 12:30:00, “arrival”, “MinmalTimeCost”, “Naples”, 14.279, 40.864, “Naples”, 14.34, 40.84). The routing system suggests departure at 14:25:10 and estimates arrival at 15:27:33. The detailed trip information is stored in the table. We also receive a ‘correct’ response and the item can be found in the server’s data table (Fig. A.4 in appendix).

Fig. A.4

Insert-IV

In the last case, we again add a new activity specified as (1, “Work”, 2011-10-05 13:00:00, 2011-10-05 13:30:00, “Naples”, 14.342, 40.864, “Jimmy”, “budget application”). This time there is a previous activity and a later activity. Two trips need to be inserted as the newly added activity has a different location compared to both the earlier activity and later activity. This time, we define the routing request for the earlier trip as: (1, “foot, bus, train”, 2011-10-05 13:00:00, “arrival”, “MinmalTimeCost”, “Naples”, 14.279, 40.864, “Naples”, 14.342, 40.864). The routing system suggests departure at 12:06:15 and estimates arrival at 12:56:05 for this trip. Next the routing request for the later trip is specified as: (1, “foot, bus, train”, 2011-10-05 12:30:00, “departure”, “MinmalTimeCost”, “Naples”, 14.342, 40.864, “Naples”, 14.34, 40.84). The routing system suggests departure at 13:30:00 and estimates arrival at 14:20:35 for this trip. Again, the detailed travel information is stored in the table. We also receive a ‘correct’ response and the item can be found in the server’s data table (Fig. A.5 in appendix).

Fig. A.5

Insert-V

1.1.2 Delete

We consider four cases to illustrate the delete operation: delete a solo activity; delete an activity where there is an activity before; delete an activity where there is an activity after, and delete an activity where there are activities before and after. We will consider the schedule that resulted from the activity insert operations explained in final stage of previous section (Fig. A.5 in appendix). We change the order a little bit to make sure that all cases can be tested.

First, we delete the second work activity: (1, “work”, 2011-10-05 13:00:00, 2011-10-05 13:30:00, “Naples”, 14.342, 40.864, “Jimmy”, “budget application”).

The travel episodes related to the activity should be replaced by new trips. For this the scheduler sends the following request to the routing system: (1, “foot, bus, train”, 2011-10-05 12:30:00, “arrival”, “MinmalTimeCost”, “Naples”, 14.377, 40.852, “Naples”, 14.377, 40.852). The routing system suggests departure at 12:01:02 and estimates arrival at 12:56:05. The database is updated and a ‘correct’ response is obtained (Fig. A.6 in appendix).

Fig. A.6

Delete-I

Next, we delete the activity with value (1, “Work”, 2011-10-05 15:30:00, 2011-10-05 16:30:00, “Naples”, 14.34, 40.84, “”, “”) which is the last activity in the agenda. Its related travel should be deleted. This is done automatically and we receive a ‘correct’ response (Fig. A.7 in appendix).

Fig. A.7

Delete-II

Then, we delete the activity (1, “Breakfast”, 2011-10-05 07:00:00, 2011-10-05 07:30:00, “Naples”, 14.222, 40.85, “”, “”) which is the first activity in the agenda. Its related travel is deleted too. We receive a ‘correct’ response and the data table has been updated (Fig. A.8 in appendix).

Fig. A.8

Delete-III

Finally, we delete the last activity left in the agenda: (1, “Work”, 2011-10-05 09:15:00, 2011-10-05 10:45:00, “Naples”, 14.377, 40.852, “Boss, Tom and Lucy”, “project progress”). After the delete operation, we receive a ‘correct’ response and the data table has been updated (Fig. A.9 in appendix).

Fig. A.9

Delete-IV

1.1.3 Update

The update operation, which can be seen as a combination of delete and insert, usually needs interface support such that the user can view all time allocations to episodes of activity and travel in sequence of scheduling. The user can then specify for example an update to utilize a free time slot. The update operation can refer to a change in one or more attributes of an activity or travel episode. For activities, changes of start time, end time or location is typically considered. For travel, most changes will be about departure time or arrival time, transport mode or travel preference (e.g. fastest, cheapest, most environmental). More complex operations can be implemented as combinations of “insert”, “delete” and “update”.

Assume an agenda that includes the inserted activities described in (Fig. A.5 in appendix). We consider the old activity: (1, “Work”, 2011-10-05 13:00:00, 2011-10-05 13:30:00, “Naples”, 14.342, 40.854, “”, “”) and update this activity involving a change in start time so that the new specification of the activity becomes: (1, “Work”, 2011-10-05 12:45:00, 2011-10-05 13:15:00, “Naples”, 14.34, 40.85, “”, “”). For the new update of the activity, we furthermore implement an update of the earlier travel: (1, “foot, bus, train”, 2011-10-05 07:30:00, “arrival”, “MinmalTimeCost”, “Naples”, 14.279, 40.864, “Naples”, 14.3, 40.85) and later travel: (1, “foot, bus, train”, 2011-10-05 07:30:00, “departure”, “MinmalTimeCost”, “Naples”, 14.3, 40.85, “Naples”, 14.34, 40.84). For the earlier travel we get a suggested departure time of 12:09:42 and arrival time of 12:39:49. For the later travel, we get a suggested departure time of 13:15:00 and arrival time of 14:10:18 (Fig. A.10 in appendix).

Fig. A.10

Update

1.2 Assistance Operations

1.2.1 Query

The query operation may be called by other activity scheduler functions or by the user-interface to display a certain time segment of a calendar (e.g., a whole day travel trace, whole day activity series). Here we assume a case where the inserted activities in Fig. A.5 in appendix are in the current agenda and define the query as:

(1, “activity”, 2011-10-05 13:00:00, 2011-10-05 17:00:00)

This query results in the following list of activities:

• 1. Work, 2011-10-05 13:00:00, 2011-10-05 13:30:00, Naples 14.342, 40.864

• 2. Work, 2011-10-05 15:30:00, 2011-10-05 16:30:00, Naples 14.34, 40.84

A query for travel episodes follows a same process. The simultaneous activity travel episodes can be easily obtained by ordering the combination list of activities and travels.

1.2.2 Indicate

Assume we have the activity data table related to user with ID 1. The indicate function performs an aggregation of the activities in the activity table and calculates the frequency of each unique activity specification in the table (for the person considered). This function can help the user in finding the most preferred attribute specification (e.g., location) for a particular activity or saving the effort of specifying all attributes of a newly planned activity from scratch. As an example of this function, Table A.1 in appendix shows the activity table (of the person) and Table A.2 in appendix shows the result of the indicate operation on this table. In this case, the template and requested attribute are both empty. This means that the filter let all activities pass through and in fact only frequencies are calculated for the profiles that are present.

Table A.1 Activities in activity table

Table A.2 Activity pattern

1.3 Dynamic Operations

1.3.1 Recommending Locations

There are four test cases for the recommend function. We assume the location type as “42”, which is shopping center. The first case illustrates the recommendation of locations from a specific point. We specify this recommendation request as:

(“A”, “”, 14.3, 40.84, 3, “42”, 2011-09-05 12:00:00, 2011-09-05 13:00:00, 10, “foot, bike train”)

where recommend type is A (recommend from user specific location); the origin position is defined by coordinates (14.3, 40.86), the maximum distance is specified as 3 km, location type is “42” (shopping center), the time window is from 2011-09-05 12:00:00 to 2011-09-05 13:00:00, available transport modes are specified as “foot, bike, train” and the planned activity duration is 10 min. We obtain one recommended location as a response:

• 1. Mercatodue, 14.301, 40.8444

The second case we consider is about recommending locations for an activity where there is a later activity in the agenda. Assume the later activity has the value:

(1, “Work”, 2011-10-05 18:30:00, 2011-10-05 19:00:00, “Naples”, 14.33, 40.84, “”, “”)

We set the recommendation request as:

(“B”, laterActivity, 5, “42”, 2011-09-05 12:00:00, 10, “foot, bike train”)

where recommend type is B (recommend where there is a later activity in the agenda), the variable name of the later activity is laterActivity, the maximum distance to later activity is 5 km, location type is “42” (shopping center), the begin time of the time window is 2011-09-05 12:00:00, the end time of time window is the begin time of the later activity—2011-09-05 18:30:00; the duration of the activity is 10 min and the available transport modes are specified with “foot, bike, train”. Now we get the following recommended locations:

• 1. Le Ginestre, 14.349, 40.8742

• 2. Sedicicasa, 14.3472, 40.8742

• 3. Il Borgo, 14.3079, 40.8734

The third case we consider is about recommending locations for an activity where there is already an earlier activity. Assume the earlier activity has the value:

(1, “Work”, 2011-10-05 09:30:00, 2011-10-05 10:30:00, “Naples”, 14.216, 40.85, “”, “”).

We set the recommendation request as:

(“C”, earlierActivity, 2, “42”, 2011-09-05 12:00:00, 10, “foot, bike train”)

where recommend type is C (recommend where there is an earlier activity in agenda) and other fields are defined similarly as before. In this case, we get the following recommended locations:

• 1. Epomeo, 14.2074, 40.8441

• 2. Galleria Scarlatti, 14.23, 40.8437

The last case we consider concerns a recommendation request for an activity where there is both an earlier and a later activity. Assume the earlier activity has the value

(1, “Work”, 2011-10-05 09:30:00, 2011-10-05 10:30:00, “Naples”, 14.216, 40.85, “”, “”)

and the later activity:

(1, “Work”, 2011-10-05 18:30:00, 2011-10-05 19:00:00, “Naples”, 14.33, 40.84, “”, “”)

The recommendation request is specified as:

(“D”, earlierActivity, laterActivity, 4, 9, “42”, 10, “foot, bike train”, “foot, bike, train”)

Where recommend type is D (recommend where there are an earlier activity and a later activity in agenda) and other fields are defined in a similar way as before. This time we get the recommended locations:

• 1. Galleria Scarlatti, 14.23, 40.8437

• 2. Galleria Umberto I, 14.2499, 40.8385

1.3.2 Detect Deviations from Schedule

The distance-based deviation detection function returns the deviation between a current actual position and scheduled position. To illustrate this, we assume here again that the activities described in Fig. 11 in appendix populate the agenda. Assume the current clock time is 2011-10-05 8:15:00 and the current position is (14.252, 40.865). We receive the response that the deviation between the current actual position and the scheduled position at this time moment is 900 m (to be precise: 898.6 m). Thus the person receives the message that he is 900 m away from the place where he had planned to be.

On the other hand, the time-based deviation detection function returns the time between the earliest possible arrival time at a next destination and the planned start time of the activity at the destination. Here again we assume that the agenda contains the activities specified in Fig. 11 in appendix. Assume the current clock time is 2011-10-05 14:00:00 and the current position is (14.3, 40.83). We receive the response that the expected arrival time is 40 min later than the planned arrival time (to be precise: 2261 s later).

The real-time event detection function returns a judgment whether a current real-time event will affect the current schedule of a user. Again, we assume here the activities described in Fig. 11 in appendix are in the agenda. Assume that the following bus arrival event:

(event, bus, 2257810, 14.240268, 40.833, arrive, 8874)

with a scheduled arrival time of 8:10:00 experiences a delay and will arrive at 8:15:00. The real-time detection function discovers that this event affects the schedule of the person considered and sends a ‘confirmed’ message which can be further handled to send an alert to the person that the bus has a delay.

Finally, we illustrate the POI location detection function. This function identifies and returns the locations of a pre-defined type that are within a certain distance from the current position of a user. Assume the type is “42” (shopping center), the current location is (14.23, 40.84) and the search distance is 5 km. Upon this request, the POI-detection function returns the locations:

• 1. Epomeo, 40.8441, 14.2074

• 2. Galleria Scarlatti, 40.8437, 14.23

• 3. Galleria Umberto I, 40.8385, 14.2499

• 4. Epomeo, 40.8476, 14.1912

• 5. Sanpaolo, 40.836, 14.1906