Modeling Approach

Overview

Our approach is to model each tourist individually as an ``agent''. The approach is adapted from one used in traffic microsimulations. A synthetic population of tourists is created that reflect current (and/or projected) visitor demographics. These tourists are given goals and expectations that reflect existing literature, on-site studies, and, in some cases where sufficient data is not available, are based on experts' estimates. These expectations are individual, meaning that each agent could potentially be given different goals and expectations.

These agents are given ``plans'', and they are introduced into the simulation with no ``knowledge'' of the the environment. The agents execute their plans, receiving feedback from the environment as they move throughout the landscape. At the end of each run, the agents' actions are compared to their expectations. If the results of a particular plan do not meet their expectations, on subsequent runs the agents try different alternatives, learning both from their own direct experience, and, depending on the learning model used, from the experiences of other agents in the system.

After numerous runs, the goal is to have a system that, in the case of a status quo scenario, reflects observed patterns in the real world. In this case, this could, for example, be the observed distribution of hikers across the study site over time.

A ``plan'' can refer to an arbitrary period, such as a day or a complete vacation period. As a first approximation, a plan is a completely specified ``control program'' for the agent. It is, however, also possible to change parts of the plan during the run, or to have incomplete plans, which are completed as the system goes.

Modular Structure

Any mobility simulation system does not just consist of the mobility simulation itself (which controls the physical constraints of the agents in a virtual world; see Sec. 3), but also of modules that compute higher level strategies of the agents. In fact, it makes sense to consider the physical and the mental world completely separately (Fig. 2). The most important modules of the mental layer are:

• Route Generator. It is not enough to have agents walk around randomly; for realistic applications it is necessary to generate plausible routes. In terms of graph language, this means that agents need to compute the sequence of links that they are taking through the network. A typical way to obtain such paths is to use a Dijkstra best path algorithm. This algorithm values individual links based on generalized costs, such as different views or different temperature levels.

• Activity Generator. Being able to compute routes, as the route generator does, only makes sense if one knows the destinations for the agents. A new technique in transportation research is to generate a (say) day-long chain of activities for each agent, and each activity's specific location. For our hiking simulations, possible activities include: be-at-hotel, visit-a-restaurant, etc. In a hiking simulations, unlike typical travel simulations, the travel ($=$ the hike) connecting these activities will generally not be seen as a negative but as a positive part of achieving their goals and expectations. As a result, for our hiking simulation the route generator module needs to connect the activities in a way such that the connecting route reflects the expectations of the agent in terms of aesthetics, difficulty, as well as travel time.

• In the synthetic population generation module, the agents are generated. This includes demographic attributes to each agent, such as age, gender, income, etc. In the future, this should follow some demographic information about the tourist population in the area of interest; at this point, this is entirely random.

• View Module This module describes to the system what individual agents ``see'' as they move through the landscape. The agents field-of-view is analyzed, and events are sent to the system describing what the agent sees. This module is introduced in section 4.2,

• Agent Databases. The strategy modules so far are capable to generate plans, and the mobility simulation is able to store exactly one plan per agent and execute it. There should, however, also be a place where plans and in particular their performance is memorized, so that memory can be retrieved later.

  The agent database modules connect all of the modules in the system. For the project described in this paper, we envisage multiple agent databases arranged in a hierarchy (Fig. 3). More about how these modules find a good strategy and how they learn from previous simulation runs can be found in section 4.

• Viewers are built so that they directly plug into the live system. The simulation sends agents' positions to the viewer, which allows to look at the scenario from a bird's eye view and observe how the agents move. It is also possible to send that same data stream to a recorder which records it to file, while a player can read the file and send the data stream to the viewer exactly the same way it would come from the simulation directly. Finally, in order to deal with data conversion issues, it is also possible to pipe the data stream from the simulation through the recorder directly to the player and from there to the viewer.

  We have implemented two different viewers. One displays a 2D view, and is suited for situations where a lot of detailed information is needed, for example while debugging (Fig. 8). Also, a 3D viewer has been implemented (Fig. 12), as one of our overall project goals is to integrate decisions based on visual stimuli. The 3D viewer connects to the simulation using the same protocol as the 2D viewer. The user can move independently of the agents or can attach the camera viewpoint to a specific agent and see the landscape through the eyes of the agent. In order to reduce code duplication, the 3D viewer is essentially the same software as the view module described above.

Figure 2: Physical and strategic (mental) layers of the framework.

Figure 3: Software structure. Logical modules and the message flows that connect them. The cloud is a ``broadcast network'', which means that all messages sent to this network are distributed to all modules attached.