GeoMason is an optional extension to MASON that adds support for vector and raster geospatial data.
A technical report giving an
overview of GeoMason capabilities is provided here, and
an article describing more GeoMason examples is here. Also, a draft of the
GeoMason is released under the Academic Free License, version 3.0.
As of August 30, 2019 the latest GeoMason version is 1.6
Since, GeoMason uses Maven, building using it will download all the 3rd party dependencies. An overview of the build process is given below. Additionally a description of the dependencies is also added for those who wish to use something other than Maven.
mvn clean installin mason-build (the root) directory
mvn clean installin the socialnets directory
make -f mvn-buildin the geomason directory
Besides the dependency on MASON itself, GeoMason relies on the Java Topology Suite for basic geometry support. For your convenience, a jar file for JTS 1.13 is provided here.
Additionally, it uses csv4j for operating on csv files and apache commons math for some math functions
Following are optional libraries
GeoMason natively supports reading and writing ESRI shape files via
classes, respectively. However, there is optional support via third party libraries for other
data formats, which are described below.
GeoToolsImporteris an optional class that uses the GeoTools library to import data in those supported formats and requires that the associated GeoTools jar files be in the CLASSPATH.
OGRImporter. Note that GDAL and OGR are native C++ libraries, and so will require that the jar files and the associated shared libraries be installed before these optional classes can be used.
Note that some of these models will require large data files. As mentioned above, they are located in jar files in geomason_data.zip (1GB) which you will need to download and add to your CLASSPATH.
These examples are provided to highlight the basic functionality of GeoMason and act as examples for how geographically explicit models can be built. The source for these demos can be found in GeoMason's
sim/app/geo directory; the corresponding data is in
Here are a few of the examples (not all of them):
This demo shows how to change the portrayal of individual geometries inside GeoMASON. Our simple example has agents randomly wandering around the Fairfax County, VA, voting districts. The shade of each district is based on the number of agents currently inside the district.
The simulation starts by reading GIS data describing the buildings, roads, and walkways of the George Mason University Fairfax campus. All the associated attribute data, such as building names, is available through inspectors. The simulation randomly places agents on the walkways and moves them along randomly. When the agents reach an intersection they arbitrarily select a new walkway line segment to continue on.
Note that this demo shows how to write a layer to a shape file. Pressing the "stop" during a simulation run will emit shape files for the building, walkway, and agent layers.
This basic traffic model explores how agents travel to Tyson's Corner, Virginia for work. The idea is that if you increased the number of agents (people) more congestion will arise. To some extent this is similar to the GeoMason
sim.app.geo.campusworld example.The model demonstrates how you can make agents move along networks (in this case road lines in the form of ESRI shapefiles) from their origin to their destination via a shortest path algorithm.
The number of agents is based census tract information i.e. the number of people who work in Tyson's Corner and their corresponding home locations which is restricted to Washington DC, Virginia and Maryland. This movie shows the fully functional model.
This model in a sense extends the Schelling Polygon model, however, instead of the polygon being the agent we take attribute data from the polygon model and create individual agents (see Crooks, 2010). This is based on the notion that much of the data we have comes at an aggregate level and often in some sort of vector representation of space such as census data. However, if we want to model the individuals or groups of individuals, we need to disaggregate the data.
To do this we create a number of Red and Blue agents based on population counts held within the polygon shapefile. As with the previous model, all agents want to be located in neighborhoods were a certain percentage of their neighbors are of the same type.
However, instead of using a Moore or Von Neumann which is common practice in cell based models. Here neighborhoods are calculated using buffer distance from the agent in question. If an agent is dissatisfied with its current neighborhood, it will move to a random location, regardless of whether or not this new location meets its preference. Moreover, the model demonstrates how to link points (agents) to polygons along with some other basic geographical operations (such as union, point in polygon, buffer). The movie below shows this movement both at the individual level and at the aggregate (census track level).
Hu (2016) developed a geographically explicit agent-based model using MASON and GeoMason to explore individual movement paths for the Syrian refugee crisis whish is shown in the Figure below. The model was built utilising open data on migration routes, sources of refugees, numbers etc. (e.g. United Nations High Commissioner for Refugees, International Organisation for Migration , OpenStreetMap) and individual agent goal selection in accordance with the theory of intervening opportunities (Stouffer, 1940). A GitHub repository contains the original model.
In this model we demonstrate how one can use polygons (such as census tracks) to create an abstract Schelling model stylized on Washington DC. The model reads in a ESRI Polygon shapefile and uses attributes of the shapefile to create Red and Blue agents and a number of Unoccupied areas. As with the traditional Schelling model, Red and Blue agents want to be located in neighborhoods were a certain percentage of their neighbors are of the same type. However, instead of using a Moore or Von Neumann which is common practice in cell based models. Here neighborhoods are calculated using the neighbors that share a common edge to the agent in question. If an agent is dissatisfied with its current neighborhood, it will move to a random Unoccupied polygon, regardless of whether or not this new location meets its preference. The movie below shows this movement.
This model demonstrates how one can use GeoMason to explore evacuations from a building. The simulation starts by reading raster data describing a building layout (converted from CAD files). The simulation randomly places a number of agents on walkable areas within side of the building. Once the agents have been placed on the ground, they follow the lowest cost path to the exit (in this example there is only one). The movie to the right demonstrates how the agents (red dots) move through the space, and through this movement congestion emerges around the exit. The yellow paths are traces of pedestrian moment.
This model shows a basic urban growth model based loosely on the SLEUTH model. In the sense, that we have only implemented the four growth rules (spontaneous, new spreading centers, edge and road-influenced growth) and not the self modification element of the SLUETH model. The model demonstrates how different layers (e.g. slope, land use, exclusion, urban extent - urbanized or non-urbanized, transportation, hillshade) can be read into a model to provide cells with multiple values. The movie below shows a specific growth scenario under specific coefficients (parameters) for Santa Fe, New Mexico.
Eastern Africa has undergone sustained drought for over a decade placing a great strain on the local population. This demo introduces an agent-based model of grazing called Turkana South. The model makes use of NDVI data and monthly rainfall data to drive vegetation growth.
Note that this demonstrates how to write a layer as an ESRI ASC/Grid format. Pressing "stop" during a simulation run will emit the simulation results as an ASC/Grid file.
Similar to Sillypeds, the elevation data acts as our terrain, in this case its Crater Lake in Oregon. Agents within the model (in this case water) fall at random over the terrain and then flows downhill over the terrain. If the water cannot flow downhill, it pools up and once the gradient is sufficient, the water flows. For example, water falling in Crater Lake, initially has to pool up until the water level is sufficient to breach the caldera. Once this occurs water flows out of the lake as highlighted in the top movie to the right.
The second movie to the right highlights the testing of the inner logic of the model in the sense are the raindrops doing as they are expected to do. If you want to test this, uncomment out (e.g. remove '//') from either one of the two lines below:
// uniform landscape, completely flat
//landscape = setupLandscape();
// landscape that slopes in
//landscape = setupLandscapeGradientIn();
These lines can be found in the start method of
WaterWorld.java file but ensure you comment out the (e.g. add '//' ) to the following line:
// read landscape from file
landscape = setupLandscapeReadIn("elevation.txt");