A DPSIR-Driven Agent-Based Model for Residential Choices and Mobility in an Urban Setting

Abstract

Sustainability in cities, and its accurate and exhaustive assessment, represent a major keystone of environmental sciences and policy making in urban planning. This study aims to provide methods for a reproducible, descriptive, predictive and prescriptive analysis of urban residential choices and mobility, which are key components of an urban system’s sustainability. Using the DPSIR framework for building agent evolution rules, we design an agent-based model of the canton of Geneva, Switzerland. The model leverages real geographical data for the canton of Geneva and its public transportation network. The resulting simulations show the dynamics of the relocation choices of commuters, in terms of the function of their travel time by public transportation to their workplace. Results show that areas around the city centre are generally preferred, but high rent prices and housing availability may prevent most residents from relocating to these areas. Other preferred housing locations are distributed around major tram and train lines and where rent prices are generally lower. The model and its associated tools are capable of spatialising aggregated statistical datasets, inferring spatial correlations, and providing qualitative and quantitative analysis of relocation dynamics. Such achievements are made possible thanks to the efficient visualisation of our results. The agent-based modelling methodology represents an adequate solution for understanding complex phenomena related to sustainability in urban systems, which can be used as guidance for policy making.

1. Introduction

As highly intertwined social, economical and ecological systems [1], urban societies evolve rapidly in the face of both demographic and economic growth, and the major challenges related to climate change and environmental impacts caused by human activity. In its Sustainable Development Goals (SDGs), which are perhaps the most widespread embodiment of the concept of sustainability in modern societies, the United Nations Development Programme (UNDP) identifies urban systems as one crucial component of the achievement of such goals (goal number 11 [2]). The assessment of the sustainability of cities, megalopolises and other urban complexes is crucial for research on urban planning, and increasingly so for policy makers as well [3,4,5,6]. Mobility, whether private or shared, motorised or not, is regarded as one of the most important indicators of the urban systems’ health and sustainability, conditioning the integrity of the populations, the economy and the landscape they comprise [7,8,9]. Smart urban planning must integrate an adapted multi-modal transportation system [10]. The need for accurate and complete representations and monitors of the many processes related to an urban system is ever-present and always growing [7,11], in particular when planning new urban developments [12]. Efficient policy making requires a full understanding and a descriptive, predictive and prescriptive analysis of such systems [13].

As highly complex systems, urban territories are often better modelled when taking into account as many of their small-scale interactions as possible [14]. Recent research suggests that most modelling endeavours that tackle these subjects fall short of representing key characteristics of complex systems, such as the importance of individual behaviours [3]. As a modelling approach from the bottom-up, which incorporates interactions of autonomous individuals with their environment and with themselves [9], agent-based modelling (ABM) stands in direct opposition with these observations, and has thus become one of the preferred methods for modelling urban processes [1,4,7,13].

However, agent-based modelling can be rough to properly execute, given the existence of a few setbacks [9]. Indeed, such a method involves a vast amount of data [9,15,16], both in input and output, that can be hard to manipulate efficiently [3], especially if their nature are geographic, spatial information. Additionally, simulation output data exploration and visualisation is particularly crucial in order to properly analyse our results and learn from them [9].

The Drivers, Pressures, State, Impacts, Responses (DPSIR) framework is an apt tool for representing and classifying the many powers which shape an urban system, with the relationships between each one of them [11]. However, it has been identified as lacking in terms of the representation of the complexity of such a system [14].

In light of these challenges, we use the DPSIR framework to represent phenomena related to urban expansion and commuting patterns in the canton of Geneva, and derive an agent-based model to compensate for the framework’s aforementioned weakness. We accompany our agent-based model with a pipeline for equipping our agents with knowledge contained in a large database, itself obtained from querying a publicly accessible API. We also build a web application for interactive and highly flexible data exploration, visualisation and analysis. All materials used and produced in the scope of this study are available in open access (https://gitlab.unige.ch/cas/Flann_ABM/mdpi-dpsir-model-1, accessed 12 June 2024).

We ask the following research questions: What benefits can the DPSIR framework bring to the design process of an agent-based model about commuting patterns and land cover change? How can we equip our people agents with knowledge about possible commuting routes during the simulations? Furthermore, what is the importance of efficiently navigating and analysing the data produced by agent-based simulations?

Key achievements of our research include the design of an agent-based model based on the DPSIR framework for representing residential decisions based on public transportation suitability for journey-to-work commutes. The different elements of the DPSIR graph we built for our use case serve as a guide for the design of the agent-based model’s evolution rules and agent behaviours. We describe the model’s assumptions and inner workings in detail with algorithms of pseudo-code, so as to foster the reproduction of our methodology. We enhance the model with an API requester for directly querying the Swiss public transportation API, and a web application for an interactive visualisation, exploration and analysis of simulation output data. After showcasing the usefulness of such methods and the benefits they bring to agent-based modelling endeavours, we produce simulations with varying initial conditions to test our model and its associated tools, and perform a critical, comparative analysis of the generated set of simulation outcomes.

In this paper, after going over our use case’s peculiarities (Section 2.1), and the state of the art on topics addressed in this paper (Section 3), we present our implementation of the DPSIR framework (Section 4.1), from which we create our model’s evolution rules (Section 4.2). We then present the input data the model uses (Section 4.3), and the python pipeline for equipping agents with knowledge during simulation runtime (Section 4.4.3). We also develop an interactive web application (webapp) for seamless exploration of output data (Section 4.4.4), which will also guide our validation process (Section 4.5). We then discuss our results for validation (Section 5.1), for the model itself (Section 5.2) and for the simulations we created from this model (Section 5.3). We review some shortcomings associated with this study and what steps can be undertaken to improve some of its aspects (Section 5.4), before ending with a summary of topics discussed in this paper (Section 6.1) and future works planned for the TRACES project (Section 6.2).

2. Background Information

2.1. Our Use Case: Urban Consolidation and Mobility in the Canton of Geneva

The territory of the canton of Geneva is densely populated, with a population of over 500,000 inhabitants over a 246 km² total land area (all figures in this section are derived from the the canton of Geneva’s portal for governmental statistics, OCSTAT https://statistique.ge.ch/, accessed 12 June 2024). The canton has enjoyed a steady increase in population, currently valued at +1.1% over the year 2022 and +1.3% over the year 2023. It benefits from high attractiveness, most notably in terms of economical influence and job opportunities [17]. The canton also juggles with the proximity of the French border; 20% of the workers in the canton are border workers—which induce high pressures not only on the transportation network inside the canton, but also to and from neighbouring France.

In 2021, public transportation represented 23% of all kilometres travelled by the residents of the canton of Geneva [18], a significant portion given the fact that all modes of transportation are included in this calculation (cars and motorcycles, bikes, walking and other transportation equipment such as electric scooters), and that travels originating from periurban areas heavily favour using the car at the expense of public transportation [18]. As they are the farthest from the city centre, periurban areas are usually where the public transportation network is least developed.

Furthermore, the COVID-19 pandemic undermined the recent trends of the usually increasing share of public transportation for mobility inside the canton [18]. As for the importance of the tram in the public transportation network, in May 2024, among 19.7 million boarding passengers recorded throughout the whole network, 8.8 million were boarding trams (data from TPG open data: https://opendata.tpg.ch/explore/dataset/montees-mensuelles-par-arret-par-ligne, accessed 12 June 2024). In the canton of Geneva, trams account for nearly 45% of the total public transportation usage, despite only representing 5 out of the total 70 lines of the Geneva public transportation system. Our model includes all 70 public transportation lines.

The spatial distribution of residential areas with respect to every resident’s workplace, and the fitness of the transportation network to accommodate such demands, are crucial parts of the urban system of the canton of Geneva. An example of urban expansion in conjunction with public transportation network development is the establishment of the Les Vergers eco-district, which welcomed in 2016 many new residents, who also benefited from the establishment of the tram line number 18 in 2010, directly linking this district to the hypercentre of the canton [19].

2.2. The DPSIR Framework

The DPSIR framework is a classification of environmental indicators and relations between them developed by the European Environment Agency in 1999 [11]. It was born from the observation that the wealth of environment indicators in use by the researcher community needs to be clearly organised and contextualised for better informing policy-making processes. Indicators and phenomena are organised into five groups: drivers, pressures, state, impacts and responses.

Driving forces induce pressures onto a given socio-economical–ecological system (SES), which modify its state and substates. This shift in the normal course of things may impact some elements of the system, such as populations, resource availability, spatial heterogeneity, etc. In response, the policy-making powers may take action aimed at either the drivers, pressures or, directly, the state of the system itself. These dynamics are represented on Figure 1.

2.3. Complexity and Agent-Based Modelling

Complex systems are perhaps best described by the following leitmotiv: “A system that is not simply, or transcends, the sum of its individual parts”, which has become quite the catchphrase whenever complexity is involved [12]. To be more precise, complexity occurs whenever a limited set of rules at a lower scale, when applied to many individual entities, give rise to complex phenomena at a larger scale. The important part is that these phenomena have never been hard-coded to occur in the system artificially. They are purely the unpredictable product of the interactions between these individual entities that are derived from simple rules. As a result, the emergence of complex phenomena and self-organisation of the system are key attributes of such complex systems [12], among other characteristics such as learning and adaptation processes of individuals, or a strong heterogeneity in the system’s population.

Cities and other urban systems are prime examples of such complex systems [1,4,7,9,12]. As coupled social, ecological and economical systems, many processes are always happening at various levels. Cities are comprised of, of course, the individual residents, but also many other organisations and other entities—such as machines and infrastructure—which are capable of autonomous decision making (sometimes indirectly) and possess their own set of guiding rules and behaviours. The actors of a city’s functioning are not only individual but also highly heterogeneous, and interact in numerous ways. Cities also encompass many topics that each correspond to fully-fledged scientific research fields, including mobility, transport management and urban planning. The strong web of interactions between all of these elements is another compelling indicator of the complex nature of urban systems [4] and urban mobility.

Agent-based modelling focuses on implementing the behaviour of a collection of individual entities called agents, in order to observe emerging phenomena at larger scales, resulting from the interactions these agents have with themselves and their environment. These self-organising properties and the high level of detail are key characteristics of such models, and the simulations they generate [9].

Agent-based modelling and the resulting simulations inherently exhibit the same key features as complex systems. Autonomous heterogeneous individuals are involved in a deep web of interactions, from which phenomena emerge [3]. They are capable of learning and adapting, and as a result, display self-organisation properties. Agent-based models are also temporally and spatially explicit [3]. As a result, agent-based models are particularly well-suited at tackling topics related to complexity science, since they capture most if not all of the key characteristics of complex systems, and urban systems are of course no exception. Agent-based models are able to represent both the individual behaviours and emergent phenomena at multiple temporal and spatial scales which make up any complex system. They represent a (very welcome) coupled bottom-up and top-down approach to modelling, which is mandatory for an astute representation of complex systems [1,4,7,10,12,13,20,21].

When designing an agent-based model for informing and guiding policy making, the DPSIR framework is an interesting inclusion for two major reasons. First of all, it is, by design, aimed at public dissemination and facilitates dialogue with policy makers [11] by organising and summarising key information. Second, the five groups of indicators and phenomena, and more crucially the causal links between them, provide solid grounds on which our agent-based model’s evolution rules can be designed. In Section 4.1, we will present our DPSIR graph and detail how we use it to design our model’s evolution rules.

2.4. Terminology

In this paper, we define terms related to DPSIR and agent-based modelling products.

• Framework: The DPSIR framework is the conceptual, general-case analysis of any complex system’s components, organising them into five types: Drivers, Pressures, State, Impacts, and Responses. This framework is the abstract, theoretical entity, that is applied to a diversity of use cases. A template representation of the DPSIR framework is pictured on Figure 1.
• Graph: From the DPSIR framework are built what we call DPSIR graphs (to be understood as a collection of nodes linked by edges, see Figure 2), which are instantiated versions of the DPSIR framework. Each use case may have one or multiple DPSIR graphs, depending on which facets of the system each graph focuses on.
• Model: We loosely use the terms “model” and “DPSIR model” for designating our agent-based model built with the help of the DPSIR framework, and of which it represents an extension. In our paper, the term “DPSIR model” never refers to the DPSIR framework or the DPSIR graphs, but rather the agent-based model itself. The “simulations” are generated from running the model itself with a given set of initial conditions and events (random or not) happening throughout the simulation’s runtime. One model may engender an endless amount of simulations.

3. State of the Art

In this section, we present the state of the art in fields related to agent-based modelling, urban processes modelling and the DPSIR framework.

3.1. Agent-Based Modelling for Urban Topics

Agent-based modelling is well-suited for urban studies in the sense that urban systems are inherently complex. Maggi et Vallino [7] describe all facets of complexity found in themes related to urban mobility—autonomous, heterogeneous individuals, with their own goals and capable of making decisions on their own, intricate interactions between themselves and with their environment, constant evolution of the system and its components, adaptation, learning, self-organisation and the emergence of transcendent phenomena. Furthermore, the authors argue that agent-based models are “useful and effective tools” to capture this aforementioned complexity and “represent complex interactions”, as well as the associated dynamics and adaptation and learning processes. Such features of agent-based models and their resulting outstanding skills in representing complexity have also been recognised by many other authors in the field [1,4,9,12,13,15,20,22].

Agent-based modelling is an innovative approach for representing complex systems, such as urban territories, and the interactions they encompass. Multi-agent systems are particularly well-suited in representing processes of urban development [1,4,7,13]. The following papers use agent-based modelling as the core method for their studies on various urban topics. Cantergiani et al. [12] study urban expansion, while taking into account interactions between three different types of agents: planners, real estate developers and the population. Gaube et al. [4] simulate residential decisions in Vienna, the capital city of Austria, and incorporate to this end heterogeneous individuals that make up the growing population of the city. They perform simulations under four different scenarios (each with its own set of initial conditions and timed events), and demonstrate the prescriptive powers of their model. Mozaffaree Pour et Oja [20] investigate what processes drive urban expansion in the city of Tallinn, Estonia. Similarly, Pavlos [16] and Xu et al. [15] build an agent-based model of urban expansion, of Athens, Greece, and Auckland, New Zealand, respectively. Gonzalez et al. [1] also focus on urban development, and examine how urban systems can best be planned to fulfil their populations’ essential needs. Orsi [13] conducts similar research by aiming to optimise urban planning to conform with the population’s desire for easily accessible green areas while still being centrally located. Tsai et al. [22] conduct a study about land use transitions and define urban surfaces as one of their land use classes. Leao and Pettit [8] focus on bicycle commutes in the city of Sydney, Australia, one of the many transportation modes that make up the urban mobility ecosystem. Previously, we also developed an agent-based model of commuting patterns along the tram line axis between Meyrin and Geneva, Switzerland [19].

3.2. The DPSIR Framework for Urban Studies

The DPSIR analysis is a widespread methodology in the recent urban-related literature, despite its age. Yousafzai et al., 2022 [23], and Yussif et al., 2023 [6], both present a DPSIR analysis graph of the urban-related process as an end product, with each obtaining different means. Yousafzai et al. present a DPSIR graph of land use and land cover change, and urban expansion, built upon “focus group discussion, expert opinion, and interviews with key persons of the relevant departments” [23]. Yussif et al. adopt a more systematic approach by progressively building their graph of urban expansion in Africa and filling the boxes with concepts expressed in the articles of their review. Qu et al., 2020 [5], present their DPSIR graph not only as an end product but also as a basis for further analysis of their case study.

3.3. The DPSIR Analysis for Agent-Based Modelling

Studies coupling agent-based modelling with the DPSIR framework are a lot more scarce. The DPSIR framework as a standalone land use model is, in some contexts, perceived as insufficient for grasping all aspects of a complex system [14,24,25]. For Haase and Schwarz, 2009 [24], one key vulnerability of such a framework is the difficulty in placing some effects into the cause or consequence boxes—sometimes, borders between these DPSIR boxes may be blurred when considering the reality of the system. According to Murray-Rust et al., 2011 [25], a flaw resides in the framework not addressing the system’s components’ evolution through time and space.

Both papers argue that the DPSIR framework is not fully adequate for taking into consideration all of the complex interactions that are quintessential to any urban system. Murray-Rust et al. [25], as well as Aguirre and Nyerges, 2014 [14], hint at the possibility of making the cogs highlighted in the DPSIR analysis framework turn, in the form of a land use model based upon such a framework. According to the Washington State Academy of Sciences (2012), cited by Aguirre and Nyerges, 2014 [14], the DPSIR framework would be a very competent portrayal of a socio-economical–ecological system’s (SESs) related processes, if it was augmented with the ability to take into account that such a complex system is “not simply the sum of atomistic individuals” [14]—which is in fact one of, if not the most important, paradigm that defines agent-based modelling.

Hence, we identify using the DPSIR framework as a foundation for building agent-based models for land cover, as an eminent axis of research in urban modelling, and dedicate this article to the presentation of one such model.

4. Methodology

This section goes in full detail about our modelling methodology, by building our DPSIR graph, deriving evolution rules from it for our model, gathering data from various sources, establishing a public transportation travel time database and enabling our agent-based model to harness the data it contains. All materials used and produced in the scope of this study are available in open access in the public repository (https://gitlab.unige.ch/cas/Flann_ABM/mdpi-dpsir-model-1, accessed 12 June 2024).

4.1. DPSIR Graph for Urban Consolidation in the Canton of Geneva

Our DPSIR graph for building our agent-based model is shown in Figure 2. At the origin of our design process for the DPSIR graph lies the state of the system. It stems from an ongoing study of the problematics around mobility and the housing market in the Greater Geneva region, which oriented the choice of elements to incorporate them as drivers, pressures, impacts and responses. A major reason for this design choice resides in the very conceptual nature of the DPSIR framework, for which it can prove challenging to determine a starting point, and in which, depending on the frame of analysis, there may exist many suitable arrangements of the elements of the studied system into each of the five DPSIR categories. This design process took place in several iterations during which the agent-based model’s requirements and technicalities related to its implementation were taken into consideration.

In our case study, the main driving force (driver) is the choice of residential place by the population of the canton. It may be motivated by many different aspects: the one we will focus on in the model is the travel time by public transport to and from the workplace, also known as the workday commute. Another factor which counterbalances this dynamic is the perceived density of buildings in the surrounding area. As a result, some agents may prefer residing in a less densely built neighbourhood, in exchange for an overall longer commute length.

This driver results in pressures on the canton, such as the amount of available lodgings, the capacity and the offer of the current public transportation system, and the satisfaction evaluation by the population on their current housing situation—is it in line with their needs and demands? Some regions and districts may feel these pressures more heavily than others because of their current state, maximum capacity and/or attractiveness. On the flip side, some pressures may be system-wide. For instance, the whole canton may feel the pressure coming from an influx of new commuters in the system—which challenges the current equilibrium of job and housing opportunities.

The state of the canton is defined by land cover indicators, such as the built density index, or more broadly, how much land is dedicated to built-up surfaces and volumes. It is also defined by the housing and mobility situation of the canton, and is intricately linked to the pressures exerted on the system, and what they apply on. We consider the state of the system as the starting point of our analysis.

Changes in these states and substates may cause impacts on the population (such as the emergence of heat islands, a phenomenon that often happens in high built density areas) or other socio-economical–ecological indicators. One example of impact we will consider in our model is the satisfaction score of each commuter: is the agent satisfied with its current situation, with regard to proximity to their workplace, living environment (surrounding building density), etc.?

Finally, potential responses are of high interest for our agent-based model. Indeed, these will drive the self-organising part of our model. In our case study, we consider that the government agent (as a decision-making party) is ready to build new residential districts at given locations, provided that a need for them has been detected. The exact locations of these new residential areas are determined by the Plan Directeur Cantonal (PDC), developed by the canton, which pinpoints which areas are suitable for such urban consolidation. Another response, which resides at a higher level, is the development of new plans for urban development, or the establishing of new policies for regulating urban consolidation or enhancing the public transportation system.

4.2. Model Evolution Rules

This subsection presents an overview of the model’s main evolution rules. Full evolution rules and behaviours are detailed in the enclosed pseudo-code (Algorithms 1–6) and the associated narrative.

(i) 

The initialisation step.

The initialisation step (see Algorithm 1) sets up the virtual world, with its basemap, government agent, job places, home addresses and PDC areas (line 4 of Algorithm 1). Each address then creates a given number of commuters, based on the information given by the addresses shapefile (line 5).

In our model, commuter agents are “synthetic people” who travel to work by public transportation every weekday; as such, we do not include unemployed people, or commuters using other transportation means (such as by car or by bike). There are two profiles of commuters. The default profile has a maximum travel time threshold default value of 35 min (line 18), and no restriction on built density surrounding their home (line 17). The other profile has a higher maximum travel time threshold (default value 60 min, line 15) but has a restriction on built density surrounding their home (default value of 10% of maximum built density value in the canton, line 14). A portion (default value 10%, line 12) of the created commuters correspond to the second profile.

We define the “commuter granularity” factor (line 2) as the amount of people in real life one agent stands for in the model. Its default initial value is 100, which means one commuter agent represents 100 people in real life.

We define the “demographic growth value” (line 2) of the model as the flat amount of commuter agents to be added to the system at every cycle. By default, a cycle corresponds to one month in the real-world system.

Once all agents have been created, a given percentage of commuters are deleted to free up some homes (line 28). Jobs are assigned to commuters (line 30), then their happiness is initialised, based on the adequacy of their home to their needs (lines 31 and 32). They check if the travel time to their job is below their own threshold, and if the built density surrounding their home is below their threshold, if applicable. The travel time to their job is retrieved from the travel time database (see Section 4.4.2) thanks to the python file watcher which runs in the background (see Section 4.4.3).

(ii) 

Reflexes and actions.

After the initialisation step, the simulation proceeds cycle by cycle by performing all reflexes at each cycle. By default, a cycle corresponds to one month in the real-world system. Starting with the first cycle, during each cycle, all reflexes are performed once. Once all reflexes have been executed, a new cycle begins, during which all reflexes are performed again once, and so on until the simulation is stopped by the user (see Algorithm 6, line 26).

Algorithm 1 Simulation initialisation. Parameters with a star (*) indicate they were defined at this phase
1: Upload shapefiles: jobs and addresses, rent price ranges per sector, PDC areas and basemap features. 2: Set initial parameter values: commuter granularity, demographic growth N, job changes per year r, proportion of commuters preferring low built density l, low built density threshold d, high travel time threshold value $t{t}_{high}$, low travel time threshold value $t{t}_{low}$, percentage of homes to free up x. 3: Locate files for communication with the travel time database (see Section 4.4.3) and delete their contents. 4: Create agents: government, rent prices sectors, job places, addresses, PDC areas. 5: Create commuter agents from addresses agents. 6:   7: $l=$ proportion of commuters preferring low built density *. 8: $d=$ low built density threshold value *. 9: for each commuter do 10:     $a_{rent}=$ current address’ rent value. 11:     Commuter’s own rent price threshold ${\mathsf{\Omega }}_{rent}\leftarrow a_{rent}$ + random floating-point number in [0.1; 2] 12:     $p\leftarrow$ random floating-point number in [0; 1) 13:     if $p<l$ then 14:         Commuter’s own built density threshold $\leftarrow d$. 15:         Commuter’s own travel time threshold $\leftarrow t{t}_{high}$. 16:     else 17:         Commuter’s own built density threshold $\leftarrow 1$. 18:         Commuter’s own travel time threshold $\leftarrow t{t}_{low}$. 19:     end if 20: end for 21: $n\leftarrow$ amount of commuters − amount of jobs. 22: if $n>0$ then 23:     Delete n random commuters. 24: end if 25:   26: Free up a portion of homes, to allow commuter relocations. 27: $x=$ percentage of homes to free up *. 28: Deletex% of commuters. 29:   30: Assign a random vacant job to each commuter. 31: Evaluate commute time $t_t$ to their job from their home with python file watcher.
32: All commuters do updateHappiness	▹ See Algorithm 3

As seen in Algorithm 2, reflex 1 (lines 6–13), at each cycle, all unhappy commuters with negative patience are flagged for relocation (line 6). They evaluate all suitable vacant homes (line 7) and examine the travel time to their job from each address (line 9). When they find a suitable new home, they move into this new home, update their happiness status and reset their patience counter (line 12, and see Algorithm 4).

All commuters also have a percentage chance (default value is 12.7% each year (OCSTAT, https://statistique.ge.ch/, accessed 12 June 2024)) to switch jobs (see Algorithm 2, reflex 2, lines 16–23). If they do, their travel time is recalculated (line 21), and their happiness status updated.

Finally, all unhappy commuters decrease their patience value by 1 at every cycle (see Algorithm 2, reflex 3, lines 26–28).

Algorithm 2 Commuter agents reflexes: executed by the commuter agents at every cycle. Parameters with a star (*) indicate they were defined at simulation initialisation
1: ${\mathsf{\Omega }}_{rent}=$ commuter’s own rent price threshold. 2: ${\mathsf{\Omega }}_d=$ commuter’s own built density threshold. 3: At every cycle, each commuter performs all of the following commands. 4:   5: Reflex 1: relocate unhappy commuters 6: if commuter’s patience < 0 then 7:     Select all vacant homes with rent $a_{rent}<{\mathsf{\Omega }}_{rent}$ and normalised built density $a_d<{\mathsf{\Omega }}_d$. 8:     for each selected home do 9:         Evaluate travel time to their job $t_t$ with python file watcher. 10:     end for 11:     The python code selects the most suitable home for the commuter, based on the $t_t$ value of available homes.
12:     Do relocate.	▹ See Algorithm 4
13: end if 14:   15: Reflex 2: change a portion of the commuters’ jobs. 16: if commuter is not jobless then 17:     $p\leftarrow$ random floating-point number in [0; 1) 18:     $r=$ spontaneous job change rate * 19:     if $p<r$ and there are vacant jobs then 20:         Change jobs for a random other job. 21:         Evaluate commute time to their new job from their home with python file watcher. 22:     end if 23: end if 24:   25: Reflex 3: decrease patience of unhappy commuters. 26: if commuter is unhappy then 27:     Decrease patience by 1. 28: end if

The government agent creates homes whenever there is a shortage of vacant homes (see Algorithm 5, lines 2–4). By default, when this reflex is triggered, an arbitrarily large volume of 10 homes are created in all suitable PDC areas, to evaluate which ones have the most demand.

Algorithm 3 Commuter agents action updateHappiness: executed by the commuter agents when called

1: $t_t=$ travel time from home to workplace. 2: $a_d=$ current address’ surrounding built density (in a 500 m radius). 3: ${\mathsf{\Omega }}_{tt}=$ commuter’s own travel time threshold. 4: ${\mathsf{\Omega }}_d=$ commuter’s own built density threshold. 5:   6: if not homeless and not jobless then 7:     if $t_t<{\mathsf{\Omega }}_{tt}$ and $a_d<{\mathsf{\Omega }}_d$ then 8:         Commuter is happy. 9:     else 10:         Commuter is not happy. 11:     end if 12: end if

Algorithm 4 Commuter agents action relocate: executed by the commuter agents when called
1: Set home to the new home indicated by the python script, and travel time to associated travel time. 2: Reset patience to its initial value.
3: Do updateHappiness.	▹ See Algorithm 3

The government agent also creates jobs whenever there is a shortage of jobs (lines 6–8). By default, when this reflex is triggered, a new job is created in a random job place.

Algorithm 5 Government agent reflexes: executed by the government agent at every cycle. Parameters with a star (*) indicate they were defined at simulation initialisation

1: $N=$ demographic growth value *. 2: if (amount of addresses with at least one vacancy) $<N$ then 3:     Add 10 homes to all suitable PDC areas, to evaluate which ones have the most demand. 4: end if 5:   6: if (amount of job places with at least one vacancy) $<N$ then 7:     Create a new job in a random job place. 8: end if

Algorithm 6 Global reflexes: executed by the world agent at every cycle. Parameters with a star (*) indicate they were defined at simulation initialisation
1: Reflex 1: demographic growth 2: $N=$ demographic growth value *. 3: $l=$ proportion of commuters preferring low built density *. 4: $d=$ built density threshold *. 5: $t{t}_{high}=$ highest travel time threshold *. 6: $t{t}_{low}=$ lowest travel time threshold *. 7: if number of jobs left $>N$ and number of vacant homes $>N$ then 8:     Create N commuters. 9:     for each of these N commuters do 10:         Rent price threshold ${\mathsf{\Omega }}_{rent}\leftarrow$ random floating-point number in [22.0; 30.0] 11:         Choose a random home, with priority given to affordable rent. 12:         Choose a random remaining job. 13:         $p\leftarrow$ random floating-point number in [0; 1). 14:         if $p<l$ then 15:            Commuter’s own built density threshold $\leftarrow d$. 16:            Commuter’s own travel time threshold $\leftarrow t{t}_{high}$. 17:         else 18:            Commuter’s own built density threshold $\leftarrow 1$. 19:            Commuter’s own travel time threshold $\leftarrow t{t}_{low}$. 20:         end if
21:         Do updateHappiness.	▹ See Algorithm 3
22:     end for 23: end if 24:   25: Reflex 2: step cycle 26: When all reflexes have been executed once, begin a new cycle, during which all reflexes will be performed once again.

At each cycle, the population in the system is increased (see Algorithm 6, line 8) if there are sufficient jobs and homes vacant (line 7), and the increase amount is non-zero (user-defined parameter). New commuters choose a random vacant home (with priority for suitable homes, line 11) and a random remaining job (line 12). Each new commuter has a given chance to be assigned one or the other commuter profile, in the same manner as during the initialisation step (lines 13–20). Finally, their happiness is initialised, based on the adequacy of their home to their needs (see line 21 and Algorithm 3).

4.3. Data Sources

In the entire scope of the study, we harness the data from four different sources: the OCSTAT (https://statistique.ge.ch/domaines/apercu.asp?dom=01_02, accessed 12 June 2024) (Office Cantonal des Statistiques) portal for governmental statistics about social and economical themes in the canton of Geneva, the SITG (https://ge.ch/sitg/, accessed 12 June 2024) (Système d’Information du Territoire Genevois) web platform for open geomatic data on the canton of Geneva and the Greater Geneva region, the TPG(https://opendata.tpg.ch/pages/accueil/, accessed 12 June 2024) (Transports Publics Genevois) open database for statistics linked to public transportation network usage in the canton of Geneva, and, finally, the Swiss train company API (CFF API, https://opentransportdata.swiss/en/cookbook/open-journey-planner-ojp/, accessed 12 June 2024) for journey planning by train and other public transportation.

Some numbers, such as the rate at which commuters spontaneously change jobs, are determined by browsing the OCSTAT website. Please see the list below for a full list of variables determined by governmental statistics.

• Average rent per square meter.
• Proportion of the population undergoing a job change at any time during a single year: 12.7% over the year 2018.

For our geospatial data needs, we download shapefiles (see shapefile list below) from the SITG. We detail pre-processing steps in Section 4.4.1.

• A grid of 200 × 200 m squares which paves the entire canton and contains information about how many residents and jobs it contains. This dataset is further enriched by adding built density data (see Section 4.4.1), then is named the “jobs and addresses” shapefile.
• A shapefile of all communes and Geneva districts that is then supplemented by information about average rent prices per square meter in that commune/district. These statistics are derived from the OCSTAT portal. The result is a rent sector shapefile for the entire canton.
• A shapefile of all PDC areas, which provides information about the type of changes the area is subject to.
• Various shapefiles for building a basemap. These include the borders of all communes, the lake and other water bodies, and the tram lines.

Public transportation journey travel times from and to any given stop in the TPG network are compiled in a database using a python script for querying the CFF API and processing the data returned. Please see Section 4.4.2 for a fully detailed methodology for building this database, and Section 4.4.3 for wiring our model with the ability to query this database.

4.4. Workflow and Implementation

This section presents all the intermediary steps we have undertaken from the data collection process to obtaining a model which is capable of generating multiple simulations with varying initial conditions. For developing our agent-based model, we chose the GAMA platform [26] because it represents a spatially explicit, versatile and powerful solution for building agent-based models [9]. Our workflow is summarised in Figure 3.

4.4.1. Data Pre-Processing

Pre-processing steps are detailed in the order of the list of shapefiles presented in Section 4.3. We wrote a python script to enrich the jobs and addresses shapefile. We first import another shapefile from the SITG, which contains all the buildings in the canton, with information about their location and their volume. Then, we apply a circular buffer of a 500 m radius to each square of the grid and sum up the volume of all buildings inside the buffer. We thus obtain a new column, which informs us of the total volume of buildings within a 500 m radius. We also create a new column to normalise each value with respect to the highest figure. This is what we called the normalised built density (within 500 m), or built density for short. This information will be harnessed by the commuter agents, who will take it into account when deciding on which home to occupy.

To build the rent sectors shapefile, the communes and Geneva districts shapefiles are downloaded and merged together. Then, a new column is created inside the table of attributes, and figures are entered one by one for each sector. These figures are read from the OCSTAT portal for governmental statistics.

The PDC areas shapefile is not pre-processed. Tram lines are obtained by downloading the shapefile of all TPG lines in the canton and filtering out all lines which are not serviced by trams.

4.4.2. Building the Public Transport Travel Time Database, with an API Requester in Python

First, we obtain a list of all stops serviced by the TPG network from the TPG open data website. Then, in python, we create a Cartesian product of this list with itself, minus the diagonal. The Cartesian product between two lists is the the matrix of pairs of all elements from the first list and all elements of the second list. Each element of the first list is successively paired with all of the elements of the second list.This results in a dataframe which contains all pairs of each stop with each other stop in the system. This dataframe will then be filled in with information about the length, in minutes, of the journey by public transportation which separates each pair of stops.

To achieve this, we create an API requester python script and query the CFF API. For each pair of stops, we format the XML sent to the API with the information it requires to successfully treat the request. This includes information about the initial and destination stop’s longitude and latitude, the request time and the time at which the journey starts, which is set to Wednesday 11 October 2023 at 8:15 am. This corresponds to an average workday during peak hour schedule. The journey length, in hours and minutes, is extracted from the returned XML and converted to an amount of minutes. For each pair of stops, multiple journeys may be available. In this case, each travel time is stored inside a list, and the minimum from this list is stored separately. In addition, the initial dataframe is supplemented with two new columns, the minimum travel time found by the API and the list of all travel times returned by the API.

This database will then be queried by the agent-based model to inform commuter agents about their mobility situation, and the mobility situation of potential new homes if they wish to relocate. Our methodology is detailed in Section 4.4.3.

4.4.3. Wiring Our Agent-Based Model with Our Travel Time Database, with a Pipeline for Communication between GAMA and Python

During the simulations’ execution, when commuters need information about travel time, they write the coordinates of their start and end points in a file. If they need information about the travel time from all potential new homes apt for relocation, they also write the address’ name and location. Once all commuters have successfully completed this step, the file is stored in a specific folder, which a python script continuously monitors. Once the aforementioned file is detected, it treats the data it contains, then deletes them. An output is generated and stored in the same folder. During this time, the agent-based model has been put in standby, awaiting the arrival of this output file. Once it is detected, the model registers the data contained inside this output file, deletes them, and the simulation continues.

First, when initialising the simulation, each commuter makes two lists of all stops in a 400m radius, one around their home and one around their workplace. For each stop, the walking distance to that stop from the respective origin is computed. We then create the Cartesian product between both lists of stops. For each pair of stops, the data about commuter name, origin address name, longitude and latitude of origin and destination stops, and total walking time (sum of both walking times) are stored inside a file. This file is then read by the python file watcher script, which retrieves the travel time from the database discussed at Section 4.4.2, for each pair of stops. The walking time is added to the travel time, and the shortest journey is selected and exported back to GAMA. The model detects this information and makes each commuter store the journey length information corresponding to their name.

Then, when the simulation advances and relocation requests are formulated, the model generates a list of all addresses with at least one vacancy left, and stores data about the name of the addresses and their current amount of vacancies inside a file. This file is also monitored by the python file watcher script and is used to inform the script if it should handle an initialisation request or a relocation request.

Simultaneously, all unhappy commuters examine all vacant addresses and exclude all those which do not match their rent price and surrounding built density requirements. The remaining addresses are subject to the same preparation as when building the initialisation request, as discussed above. This means that each commuter sends a request for each address that it has deemed suitable for relocation, instead of the single initial address they call home.

Because the python script detected a file containing information about addresses with vacancies, it enters a new series of commands after finding the shortest travel time for each address-to-job journey. It will assign each commuter one address among the list they have considered if the travel time is lower than their accepted threshold. The script assigns the first valid candidate in the list. If after going through the whole list, no valid candidates are found, then nothing is returned for that commuter in particular. This can happen either because all travel times are higher than the accepted threshold, or because no more vacancies are left in the addresses the commuter was interested in. Indeed, when assigning an address, the amount of vacancies is reduced by one. The amount of vacancies is in fact changed dynamically after each relocation and taken into account in the next relocation attempts. In the end, the python script sends back, for each commuter, either zero or exactly one address to GAMA.

The agent-based simulation then reads this information and each commuter will move to the address indicated by the python script if it exists.

4.4.4. Building and Deploying a Web Application for Simulation Data Exploration and Visualisation

Navigating simulation output data can often prove particularly arduous. Simulation output datasets typically contain a set of multiple variables of each agent, of which there are also many types. The value of each variable is recorded for every cycle of the simulation. Spatially explicit simulations may also export the exact position of each agent at every cycle.

We develop a web application with the help of the Dash python library for the visualisation, exploration and analysis of our simulation output data. We also deploy this application to the following website: https://dpsir-model-app.azurewebsites.net/, accessed 12 June 2024. This lets any user access the tool with all of its features through a simple browser window. Alternatively, we present some of the plots and maps the application is able to create in Section 5.3.

Our web application is able to represent, in a spatially explicit way, the state of the simulation and any agent-related and world-related variables, at any given cycle, and replay the simulation at any point without the need for executing the simulation again, with the added options of fast-forwarding and rewinding time. While the GAMA platform is able to provide plots of any given variable in real time, these specific advanced tasks are not possible during the simulations’ runtime.

A detailed description of the components of the application follows. The application’s header contains details about the initial conditions for that particular simulation, such as the population growth, the proportion of commuters selecting low built density homes, the threshold for designating an area as “low built density”, the commuters’ initial patience, the method for creating new homes, etc. Then, sections are numbered from A1 to A3 and C1 to C3, for graphs and maps about, respectively, addresses and commutes. Towards the middle of the application, between sections A3 and C1, a numbered line and an input box allow for browsing through cycles of the simulation, much like a timeline.

Section A1 presents a plot of the evolution of the mean values of key attributes of the addresses agents through time. These attributes are, in order, the amount of commuters they house, the number of vacancies, the number of new homes created and the number of commuters having moved in and moved out.

Section A2 is linked to the map in section A3. It plots the evolution through time of the same key attributes of the selected address in section A3.

Section A3 is a map of the addresses in the canton at the cycle number selected in the timeline. Each address is represented by a circle, the colour and size of which can be made to correspond to the value of any of the five key attributes, plus the average rent at that given address. Clicking on any address on the map selects it for the plot in section A2.

Section C1 is a map of the commuters in the canton at the cycle number selected in the timeline. Each commuter is represented by a circle, the colour and size of which can be made to correspond to the value of any of their five key attributes. These attributes are, in order, the maximum rent price the agent tolerates, its travel time from home to work, its happiness status, its patience counter and the amount of relocations it went through. Clicking on any commuter on the map selects it for the plot in section C2.

Section C2 is linked to the map in section C1. It plots the evolution through time of the same key attributes of the selected commuter in section C1.

Section C3 presents a plot of the evolution of the mean values of key attributes of the commuters agents through time. It is also equipped with an input box, which should receive the real-life figure for the amount of relocations per year, expressed as a percentage of the total population. This value defaults at 9.6% and will be useful for validation, as discussed in Section 4.5. When selecting a plot for the amount of relocations, along with the usual red curve for the simulated data, a green curve displays the amount of relocations computed from the real-life figure entered in the input box.

4.5. Validation Method

For the validation of our model, we compare the total amount of relocations among all canton residents in both the simulation and the real-life situation. The official portal for governmental statistics (OCSTAT), informs us of the relocation rate over the years 2007 to 2022. In 2022, the total amount of relocations was equal to 9.6% of the total population, or 0.8% per month. We compare this evolution with the amount of relocations in the simulation, expressed as a percentage of the total population in the model:

$$\mathit{relocation} \mathit{rate}={\displaystyle \frac{\mathit{total} \mathit{number} \mathit{of} \mathit{relocations}}{\mathit{total} \mathit{population}}}\times 100\%$$

(1)

In the web application, the very bottom plot is equipped with a number input, which corresponds to the target real system relocations per year, expressed as a percentage of the total population. The green plot will evolve based on the number the user inputs in this box (default value is 0.096 = 9.6%). This feature lets us evaluate the adequacy between both curves more easily, which in turn facilitates the validation process.

5. Results and Discussion

This section presents all of our results in the scope of this study, accompanied with a discussion on these results and our methodology. We ran the model a total of six times, with differing initial parameter values, and obtained as many simulations. A summary of each simulation’s initial parameter values and agent count is presented in

Table 1. Initial parameter values and agent count at simulation end for all 6 simulation output datasets.

	Sim. 1	Sim. 2	Sim. 3	Sim. 4	Sim. 5	Sim. 6
Population growth [agents]	0	0	0	0	0	+5
Proportion of commuters preferring low density	0	0	0.1	0.2	0.2	0.1
Low built density threshold	0.1	0.1	0.1	0.1	0.2	0.1
Initial patience range [months]	10–14	5–7	10–14	10–14	10–14	10–14
Amount of addresses (sim. end)	1151	1151	1151	1151	1151	1151
Amount of commuters (sim. end)	2730	2730	2730	2730	2730	2825

. Each simulation output dataset was then analysed thanks to the data visualisation and exploration platform.

5.1. Validation Results

The model itself uses data from the real-world system it focuses on. Indeed, all shapefiles are from the SITG portal for geomatic data about the canton of Geneva, and the model incorporates the spatial positions and other variables of all the objects it uses. Key values, such as the spontaneous job change rate and the travel time by public transport from one stop to another, are derived from the real-world data, such as the OCSTAT statistics and the Swiss public transport API available to all passengers. These design choices enhance our model’s conformity with the real system’s functioning.

Furthermore, we compare the dynamics of simulation 6 in terms of relocation rate, with the real-world data (for methodology, see Section 4.5). We chose to use this simulation as the validation of our model since it incorporates the population growth factor. In this simulation, five commuter agents are added to the simulation every cycle. This corresponds to 500 new people in the system every month, or 6000 per year, when factoring in the commuter granularity default value of 100. This figure is in line with the range of values for demographic growth in the canton of Geneva: between 5500 and 6500 new residents per year (data from OCSTAT). The validation results are shown in Figure 4.

After running the simulation for three full years (36 months), despite some differences in the shape of the curves, the orders of magnitude are coherent between both curves. The differing shape of the simulation data curve can be explained by two peculiarities in the model’s functioning. First of all, the initial patience of all commuters in the system is set to at least 10 at initialisation. This patience decreases by 1 each cycle if the commuter is unhappy (see Algorithm 2), but nothing happens until the patience value becomes negative. This explains the flat curve from cycle 0 to cycle 9. Then, at cycle 10, the relocation requests from unhappy commuters are triggered, and commuters start relocating, which is when the simulated data curve starts adopting the same behaviour as the validation data curve. In parallel, the population growth induces a reduction in the amount of available housing and job places. The government agent reacts by creating 10 homes in all PDC areas suitable for housing (see Algorithm 5), which prompts a massive increase in the number of relocation requests. This is visible at cycle 15 on the plot. Finally, from cycle 16 onwards, the simulation is characterised by a steady increase in the number of relocations, which is driven by the regular influx of new commuters in the system.

On the other side, the validation data assume a constant relocation rate that is not influenced by any modelling assumptions or behavioural gimmicks. When discarding the peculiarities pertaining to our model’s behaviour, the orders of magnitude of the simulated data and the real-world data are coherent, and the average amount of relocations over three full years in both datasets are in line with each other.

While our model’s components are based upon real-world data, the elements presented in our validation process are not sufficient to guarantee a complete validation of our model, but rather a partial one. They ensure our model is in general agreement with reality, and that it has been built on the basis of real-world data, but leave out some margin of error that prevents the model from providing a flawless and accurate quantitative analysis of some phenomena (especially future ones). Strengthening our validation process would require further studies and resources that lie outside the scope of this paper. We discuss possible works in this direction in Section 5.4.

5.2. Model Results and Discussion

The methods we used to develop the agent-based model provide preliminary answers to our original research questions. The DPSIR proved useful specifically for designing our model’s evolution rules, in a way that adequately incorporates our studied system’s main components. We paired this model with a pipeline that queries the Swiss public transportation API for travel times in the canton of Geneva, and that sends this information to our commuter agents. This pipeline and the simulation run in parallel, thus conveniently equipping the agents with knowledge about daily commute travel times. Finally, the importance of data visualisation in the agent-based modelling field will be discussed later in this study when we analyse our results thanks to the dedicated web application.

5.3. Simulation Data Analysis and Discussion

All plots and maps presented in this section are directly derived from the web application for data analysis and exploration. For each simulation output dataset, the app may be launched by running the app.py python script in the corresponding folder. All simulation output datasets are included in the ‘OutputDatasets’ folder in the shared repository (https://gitlab.unige.ch/cas/Flann_ABM/mdpi-dpsir-model-1, accessed 12 June 2024) for this paper.

We present and discuss an overview of the possibilities offered by the data analysis web application to paint a clearer picture of how well it blends in and complements our agent-based modelling endeavours. In Figure 5, we present a map of the average rent prices across the canton, obtained at month 1 of simulation 6. For each address, the size of the circle represents the number of commuters residing there in the simulation, and the colour of the circle represents the average rent price, expressed in CHF/m². This choice of symbology is freely left to the user, who can easily change what they wish to observe on the map thanks to the radio items menu pictured on the left side of Figure 5.

As the commuter granularity factor was set to 100 (on average, one agent represents 100 people in real life), only addresses with a substantial amount of residents are represented on the map. We observe a general trend of the rent price and the population density increasing as one approaches the city centre, as indicated by the large yellow and orange circles. The rent prices are generally the lowest at the western peripheral part of the canton, in communes such as Vernier and Onex.

The inclusion of this particular map highlights one of the strengths of agent-based modelling and the associated simulations. We started with aggregated statistical data, and spatialised this dataset by using geomatic data processing tools. We then ran the simulation and used its self-organisation properties to obtain the spatial distribution of commuters with our modelling assumptions. Thus, agent-based modelling is able to both spatialise and enrich statistical datasets, which can have a myriad of follow-up applications.

Displaying the spatial distribution of and relationship between other key indicators of the model is as simple as changing the selection of items in the radio items menu pictured on the left panel of Figure 5. For instance, Figure 6 represents the amount of commuters having moved in and out of each address for simulation 4 (month 36). From this map, it is possible to have a glance at which spatial locations experience the most relocation dynamics. For instance, addresses located towards the centre of Geneva are generally preferred when moving in, indicated by the circles being generally larger towards the city centre and smaller at the peripheries. However, housing availability and high rent prices may severely limit the amount of commuters who are able to move into these addresses, despite initially wishing to do so. From the yellow and orange colours of the circles, one can deduce that the homes from which the most commuters decided to move out of are located in Meyrin (west, towards the airport) and Versoix (north), with two specific addresses towards the city centre displaying the highest count.

As pictured in Figure 7, a map of the canton also exists for the commuters themselves. This map offers the same possibilities for a user-defined symbology as with the addresses map (as seen on Figure 5). Figure 7 represents the happiness status of commuters at month 5 (left) and month 36 (right) of simulation 4. The first observation that can be made is that the overall satisfaction of commuters in the system increases, with visibly fewer unhappy commuters at month 36 than at month 5. This is directly correlated with the relocation dynamics of the model, which implies unhappy commuters systematically seek a suitable home and move out when they find one. These two maps also give context to the observations made above for Figure 6. Meyrin, Versoix and two particular addresses in the city centre saw the most commuters moving out. While this fact is correlated with the high count of people residing in these areas, the analysis of the happiness map at these specific locations allows us to identify a spatial correlation between the happiness status at the start of the simulation and the move-out probability. Indeed, the town of Versoix is initially marked by an extremely high proportion of unhappy commuters, as is the case with Meyrin and the city centre, albeit at a lower degree. This highlights another strength of building spatially explicit plots as part as our model’s results analysis process: the ability to pinpoint spatial correlations between key indicators of our model.

The data analysis app also quantifies the evolution of these indicators through time. Figure 8 shows the evolution through time of the average travel time (left) and happiness status (right) of commuters in the system for simulation 4. While the average travel time steadily decreases after the commuters start relocating to a more suitable home, the proportion of satisfied commuters increases in a similar manner. This behaviour may be observed in all other simulations, and quantifies the trend identified above for the amount of happy commuters on the map (see Figure 7) in terms of the function of time. As a side note, this interactive plot module on the web application is also equipped with a radio items menu, which lets the user choose and cycle through the various key indicators in order to easily visualise their evolution though time.

We now analyse, for each simulation, the evolutions of the amount of relocations in the system and contextualise them with the discrepancies between each set of initial conditions. This will let us appreciate the sensitivity of our model to changes in the initial conditions. For all six simulation output datasets, we plot the relocation rate in the system in terms of the function of time (Figure 9, Figure 10 and Figure 11). The real-world data curve is also represented in green for context.

Simulation 1 corresponds to the most basic setup, with no population growth, and no desire for a low built density environment. Once the patience of the unhappy commuters runs out at month 10, a rapid increase in relocation rate is to be seen, which eventually settles to a much lower rate.

Simulation 2 divides the average initial patience by 2. As a result, the relocations happen as early as month 5, which can be seen on the plot.

Simulation 3 reinstates the minimum initial patience value of 10, and introduces a new profile of commuters: 10% of the commuters will prefer living in an environment with a built density strictly less than 10% of the maximum built density in the canton:

$$\mathit{preferred} \mathit{built} \mathit{density} \mathit{within} \mathit{500}\mathit{m}<10\%\times \mathit{maximum} \mathit{cantonal} \mathit{built} \mathit{density}$$

(2)

In return, the travel time threshold for these commuters is set to 60 min instead of 35 min. The plot of the relocation rate for this simulation shows a smoother curve than for simulation 1. The initial increase happening at month 10 onwards is not as sharp, and there are overall fewer relocations than in simulation 1. This is because of the threshold rise for part of the population: some commuters that were unhappy because their travel time exceeded the low threshold may become happy if their threshold value is raised.

This behaviour is further shown on the plot for simulation 5. In this simulation, the proportion of commuters preferring a low built density but accepting a higher travel time threshold is brought to 20%. The low density threshold is also brought to 20%. The plot shows that the increase in relocations is much smoother, and the total amount of relocations is the lowest of all simulations.

In simulation 4, as the proportion of commuters preferring a low built density but accepting a higher travel time threshold is kept to 20%, but the low built density threshold is brought back down to 0.1%, the increase in relocations is sharper and the amount of relocations is higher. This is because commuters may be unhappy not only because of a high travel time but also because the surrounding built density is too high. This cause is more likely to happen than in simulation 5 because of the lower threshold value. This results in a higher relocation likelihood.

Finally, the behaviour of simulation 6 has already been discussed in the validation section of this paper (see Section 5.1). The large step that can be seen is linked to the sudden creation of a large amount of homes in the PDC areas by the government agent, and the steady increase in relocations that happens afterwards is linked to the continuous influx of new commuters in the system. The establishment of these new residential buildings impacts the sustainability of these regions as they influence metrics about the built-up area.

This section would not be complete without taking a look at the results of simulation 6. As a reminder, the goal of this experiment was to determine which addresses are the most attractive for incoming commuters (a result of a steady population growth). The government agent was tasked to create an arbitrarily large amount of new homes in all PDC areas. Figure 12 shows, in yellow circles, which locations were chosen by the arriving commuters. Only the newly created addresses are shown. The eastern part of the canton around Chêne-Bourg, the northwestern axis towards Meyrin and the southern part of Lancy appear to be the most attractive. Housing in these areas is on average cheaper than around the city centre of Geneva, as can be seen on Figure 5. Since, in our model, the commuters’ happiness and willingness to move into a given home is heavily tied to the travel time to work by public transportation, the attractiveness of the first two regions can be explained by the presence of the trams 12 and 14/18, respectively, and for the southern part of Lancy, the proximity of the two train stations of Lancy-Pont-Rouge and Lancy-Bachet, which all allow for fast and convenient access to the city centre, where the most workplaces and overall businesses and shops are located.

To answer our third research question, a visually appealing presentation of results and data is highly valuable for the agent-based modelling field [9]. We have developed and used a data exploration platform, and showed that compelling data visualisation tools may help achieve multiple tasks, such as the spatialisation of aggregated data and the identification of spatial correlations. Efficient visualisations are capable of showcasing and explaining key emergent behaviours observed in the model—a remarkable trait when considering the critical and exigent need for an accurate assessment of the sustainability of urban systems [4,5,6]. Creating a web application for data visualisation and analysis is one possible way to ensure an effective dissemination of our study’s results.

5.4. Moving Forward: Shortcomings and Possible Improvements

To enrich our closing discussion, we point out some shortcomings of our study and steps towards addressing them, and discuss possible works that would improve this study.

Much like a double-edged sword, one limitation of the model and its subsequent simulations resides in the use of the API for computing journey travel times. These data are fixed at a particular recent date, which is adequate for representing the system in recent timelines and grounding our model in the reality of the system. However, this facet makes it difficult to use the model to represent past trends. For this accomplishment, the use of the model as is would come with the flaw of an inaccurate representation of the public transportation system state at the given date of the study. Since the public transportation API does not allow a lot of freedom in the dates used for computation, a recreation of the public transportation network at different points in time, and the computation of the travel times at different points in time based on this remodelling, would have to be systematically undertaken for the model to be able to accurately accommodate different timelines than the present.

As discussed in Section 4.5, we could only achieve a partial validation of our model. The discrepancies between the simulated data and the real-world data were explained but subsist nevertheless. Integrating stochasticity in the agents’ behaviours could smooth out the large jump in the amount of relocations observed in the simulation, and place the model in better agreement with reality. For instance, people agents may have a probability of moving out in each cycle they are unhappy (i.e., their patience value is negative), instead of automatically doing so as soon as their patience runs out. Another interesting behaviour to investigate would be the government agent’s: instead of making a large amount of homes appear at every possible address, a smaller amount of new homes would be spawned randomly in a limited selection of addresses.

However, this would add more parameters to consider when building the model, which highlights another difficulty: the sheer immensity of the parameter space that usually comes with any agent-based model, and the daunting task of calibrating the values of all of these parameters [15]. One way to tackle this challenge is participatory modelling. The involvement of experts on the topic, policy makers and any other party capable of providing valuable insights, right from the start of the agent-based modelling project and during the entire model development phase, can help us reduce this parameter space to focus on processes that garner the most interest [27]. They can suggest the inclusion of this or that parameter and set it at such a value, or of some key behaviour, and help design relevant what-if scenarios. Calibration is greatly facilitated and backed up by knowledge and evidence. It follows that the validation process can also be enhanced by the guidance of experts, which further grounds the model in the reality of the terrain.

Participatory modelling can be seen as a major keystone of efforts to increase the policy-making guidance powers of agent-based models. In that context, opportunities arise from embedding agent-based models into digital twins by providing the necessary accompanying infrastructure. Digital twins may represent concrete manifestations of an agent-based model being used to inform governmental parties, develop new policies and support urban planning [10,21,28,29,30,31,32,33]. We plan to investigate this matter in future research. On a side note, the works conducted in the scope of this study have piqued the interest of local authorities (more specifically, the GE2050 consortium, an initiative from the canton of Geneva to tackle sustainability by 2050), which could lead to future collaboration of this sort.

The pipeline also shows the possibility of directly querying the API during the simulation runtime for building a connected model that could be used to represent real-time movements of commuters in the system.

Another improvement for our model would be the inclusion of more attributes for our people agents, such as age, gender or job type. These factors can considerably influence personal decisions such as which suburb to live in or the preferred transportation method for daily commutes. Such attributes have been integrated in our previous study, which focuses on a particular axis of the Geneva transportation network [19].

Finally, transferring the model to other use cases would be a compelling axis of improvement, which is made possible by the high modularity of agent-based models. It is entirely possible to keep a model’s rules of evolution (or tweak them to account for the peculiarities of a given use case), and replace existing datasets by those of another area. For instance, to transfer the study to the city of Dijon (France), the geometry of the virtual world and datasets such as the spatial distribution of the population and travel times by public transportation would be those of the city of Dijon (instead of Geneva), while the people agents would still exhibit the same behaviours as the model for Geneva (such as relocating when unhappy, and becoming unhappy when commute travel time is above a given threshold). Such endeavours would not only be interesting for the new systems studied but also for the model itself: if a sound analysis can be provided by the model for other use cases as well, then its validity is further proven.

6. Conclusions

6.1. Summary

We conducted a DPSIR analysis of mobility and residential decisions in the canton of Geneva, Switzerland, which we then harnessed to design evolution rules of a dedicated agent-based model. This model is equipped with a pipeline for querying the official public transportation API, compiling the received data and transferring these data to the agents when they need them during the simulations. To solve issues relating to the visualisation and analysis of the heaps of data produced by such simulations, we built a multi-purpose data visualisation, exploration and analysis platform, which not only streamlined the validation process of our model and the analysis of our results but also enabled their efficient dissemination—through the deployment to a web application. Results show that the model is indeed capable of representing residential choices dynamics in the function of the public transportation offer, the state of which is directly sourced from the official public transportation API. Rent prices are generally highest around the city centre of Geneva, and lowest in the western part of the canton. When possible, people prefer relocating to homes that are closer to the city centre; however, this desire is heavily moderated by rent prices and housing availability. From there, priority shifts to residences located near modes of public transportation with high passenger capacity and travelling speed, such as tram lines 12, 14 and 18, and trains, and where rent costs less on average as well.

The data exploration platform (https://dpsir-model-app.azurewebsites.net/, accessed 12 June 2024) associated with the model is an example implementation of an efficient data visualisation tool for agent-based models. Compelling visual assets allow for interactive, exhaustive exploration of simulation output data, which promotes efficient communication about agent-based modelling studies and facilitates the analysis, discussion and dissemination of simulation results. All methods are thoroughly documented (https://gitlab.unige.ch/cas/Flann_ABM/mdpi-dpsir-model-1, accessed 12 June 2024), ensuring the reproducibility of our experiments.

6.2. Future Works

This paper is a part of the TRACES project, a workgroup for analysing Semantic Environmental Trajectories of the greater Geneva (Switzerland), Evian-les-Bains (France) and Fribourg (Switzerland) Territories (SETT). Previous work by the authors includes the development of an agent-based model for representing commuting patterns along the Cornavin–Meyrin–CERN axis, and the emergence of new buildings and residential districts along this same axis; as well as state of the art research on techniques used in agent-based modelling. Future endeavours build upon the groundworks laid by these studies—an agent-based model for linking land cover change and the emergence of new public transportation axes is currently under work. This model will harness most of its needed data about the world’s initial state from a knowledge graph, built with a python library tailor-made for this experiment. Through a jupyter notebook interface, this python library will enable anyone—researchers, policy makers, any member of the population—to create a knowledge graph recounting past events and testing out scenarios for the future evolution of the canton of Geneva, which will automatically be integrated into the model. The latter will then be able to enrich this knowledge graph with the emergent phenomena created by the self-organisation properties of the agents.