ABMland-a Tool for Agent-Based Model Development on Urban Land Use Change

Modelling urban land use change can foster understanding of underlying processes and is increasingly realized using agentbased models (ABM) as they allow for explicitly coding land management decisions. However, urban land use change is the result of interactions of a variety of individuals as well as organisations. Thus, simulation models on urban land use need to include a diversity of agent types which in turn leads to complex interactions and coding processes. This paper presents the new ABMland tool which can help in this process: It is software for developing agent-based models for urban land use change within a spatially explicit and joint environment. ABMland allows for implementing agent-based models and parallel model development while simplifying the coding process. Six major agent types are already included as coupled models: residents, planners, infrastructure providers, businesses, developers and lobbyists. Their interactions are pre-defined and ensure valid communication during the simulation. The software is implemented in Java building upon Repast Simphony and other libraries.

Although more than half of the population worldwide now lives in urban areas and consumes land and other resources, urbanisation is scarcely understood.Modelling urban land use change can foster understanding and is increasingly done with agent-based models (ABM) as they allow for coding land management decisions (Matthews et al. 2007;Parker et al. 2003;Schwarz et al. 2010;Wu & Silva 2010).In ABMs, individual agents act as autonomous entities towards realising own goals and interact with their environment and other agents.Some applications encompass a large number of agent objects that do differ in their attributes, but not in the behaviour rules, such as households (Haase et al. 2010).More complex models comprise of different agents like buyers and sellers of land with different decision rules (Filatova et al. 2009).Agents can either control land use change directly or indirectly (Parker et al. 2008).Such complex simulations are necessary for simulating urban land use change as urban sprawl as well as urban shrinkage are influenced by decisions of different groups of individuals and institutions, e.g.households, urban planners or developers (Schwarz et al. 2010).What is more, decision processes are structured differently in different regions.
1.2 Such complex simulations are very likely not developed by a single investigator, but a group of researchers, probably from different institutions (Cioffi-Revilla 2010).The joint design and implementation of programming code by different modellers or groups can be fostered by toolkits that facilitate the coding process and the coupling of the single models.
Simulation models in general can on the one hand be coupled using existing generic solutions, e.g.Geonamica (Hurkens et al. 2008), openMI ( http://www.openmi.org)or Object Modeling System OMS ( http://javaforge.com/project/oms).On the other hand, project-specific solutions for coupling ABMs are tailor-made for the simulation in question (e.g.Barthel et al. 2007).We describe such a new tool that provides the infrastructure to couple different ABM for urban land use change.In the current version, six ABMs are included: residents, businesses, planners, developers, infrastructure providers, and lobbyists.

Software features
2.1 Scheduling.The single ABMs follow a common scheduling that distinguishes initialisation, data exchange, and computation.Data exchange and computation run for each time step, while initialisation takes place only at the beginning of a simulation.A controller to store and update commonly used data, such as land use and prices, is implemented.Its computing cycle is executed before the single ABMs.

2.2
Interfaces.Specified data types (e.g."household number") make sure that only a pre-defined data type ("integer") within upper and lower boundaries (0 to 10,000) is communicated.

2.3
Space.One or more grids can be used to allocate agents or land use.The software provides helper classes for importing and exporting basic spatial data.

2.4
Default behaviour.For each ABM, the "standard" behaviour needs to be coded in the respective default model implementation.This mechanism ensures that the coupled simulation can be executed even if concrete implementations are not available for all models.The standard behaviour might simply encompass static values that should be exported in every time step or include more dynamic responses.As soon as the concrete model implementation extends the default model implementation, the standard behaviour is not used, but the fully implemented version itself.The ABMland tool consists of JPF (Java Plugin Framework) plugins that build upon Repast Simphony and other libraries in form of regular jar files.Additionally to the ABMland framework, a toy model is provided to exemplary show the usage of the framework.This toy example of infrastructure providers and residents indicates where meaningful parameters and methods should be included.

3.2
Coding models and agents.Various interactions have been implemented between the models (and therefore indirectly between their agents).A number of specific data types are already pre-defined.Thus, coding the concrete models is straightforward: The methods to export data needed by other agents are already given, and each model only needs three more methods: init(), getData() and compute() with annotations to ensure the correct scheduling.Modellers are free to design their agents and additional classes as they like, as long as they do not interfere with the scheduling and use the model's scheduled classes to call all other methods.

3.3
Changing default behaviours.In the default implementation of each model, pre-defined values for each of the export methods are already implemented to ensure that some interaction takes place even if the full model has not been finalised yet by the modeller.For instance, planning agents in the default implementation randomly permit or deny proposals to change land use.To change this, the export methods in the respective default implementation have to be adapted.

3.4
Additional features.The ABMland tool also provides helper classes for input and output.The tool provides methods to import ASCII raster data as well as configuration files in XML format and some spreadsheet formats (csv, xls).Simulation results can currently be exported as log files or csv files.Finally, the ABMland tool also encompasses additional utilities to use Repast Simphony functions.To include new data types, they need to be added with annotated boundaries into the respective package.For one agent type (and thus for one model), the framework consists of a default implementation, a server and an interface.The interaction of these three constructs makes sure that at least the default implementation can deliver pre-defined values in a coupled simulation if one or more models are still under development (Figure 1 in the main text).Each model extends a default implementation providing dummy values in case no concrete implementation for a specific model is available for a coupled simulation.This default implementation extends an interface that lists all the methods the model uses to export data.Servers forward the data to a coupled model.The server gets the information via the interface and either receives the data from the concrete model implementation or from the default implementation, if there is no concrete implementation available.

Concluding remarks
A.2 Thus, communication between agents is indirect, i.e. their respective models exchange the information via servers.This mechanism enforces a model to implement the exact export methods.This is crucial for ensuring communication during the coupled simulation.Specified data types (e.g."household number") make sure that only a pre-defined data type ("integer") within upper and lower boundaries (0 to 10,000) is communicated.Agents only receive the data that are provided by the interfaces, i.e. they do not know the source of the data.Thus, the information transported to the agents depends on the definition of the interfaces.If it is not sufficient for the ResidentAgent to know the mere location of a public transport stop because it also needs to know the specific bus line, then this information needs to be added in the interface.This is done by including a parameter to the definition of the data type which then states for instance the number of the bus line, in addition to the location of the bus stop.Controllers store and update commonly used data (land use and land prices).Spatially explicit data are wrapped into the Repast Simphony grid value layers.

Figure 1 .
Figure 1.An overview of ABMland.Implementations of single ABMs (here: infrastructure providers and resident) communicate indirectly via server, interface and default model implementation as provided by the software.Results are exported as maps or aggregated data Adapting the tool.The ABMland tool can be adapted to (a) include other models and/or (b) data types.For (a), users have to modify the model.scorefile of their Repast Simphony simulation project, for each new model implement a default implementation, a server and an interface, add two context classes (for model and agent).
We described a tool to implement a coupled simulation consisting of six ABMs to model urban land use change.Using the ABMland software, one can easily experiment with different versions of the ABM because data exchanges are fixed.For instance, an infrastructure provider model representing central European planning regimes can be easily exchanged with an infrastructure provider model developed for Northern America.As a trade-off these models may be inconsistent in terms of their representation of reality.However, the ABMland software provides the opportunity to develop coupled ABM on urban land use change as single components can be implemented with a lot of freedom.Furthermore, the software can be adapted to include other models and/or data types.It not only provides an implementation to couple specific ABMs on urban land use change, but also gives the opportunity to adapt the general coupling principles for other applications.Email: abmland@ufz.deAvailabilityViahttp://www.ufz.de/abmland,Apache 2each agent type, exactly one model class is implemented that encompasses all its behaviour.This model class has three main tasks: to include this part of the simulation into the overall scheduling of the coupled simulation, to control its own agent(s), and to exchange data with all other models and the environment.Splitting up the overall control / data exchange and the agent has the following advantage: One entity is coupled to the rest of the system in terms of scheduling and data exchange (= the model), while one or more entities (= the agents) are controlled by the model.Thus, only the model has to fulfil a few requirements, while the agent is not visible for the other parts of the coupled simulation and can therefore be coded without restrictions (Figure A-1).

Figure A- 1 .
Figure A-1.The relationship of model and agent illustrated with the infrastructure provider model.In the infrastructure provider model, scheduled methods as well as methods exporting data are public and can thus be used from outside the class (indicated with '+').Neither the infrastructure provider agent(s) nor its attributes and methods are visible (indicated with '-')

Figure A- 2 .
Figure A-2.Activity diagram for controllers and models