Geospatial Support for MASON

Evolutionary Computation Laboratory and
Center for Social Complexity
George Mason University

About GeoMason

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 Cookbook contains "recipes" covering common GeoMason use case scenarios. The class API documentation is available here.

GeoMason is released under the Academic Free License, version 3.0.

As of August 30, 2019 the latest GeoMason version is 1.6

What's New

August 30, 2019 -- GeoMason 1.6 Released
The new version of GeoMason uses maven for dependency management

Getting GeoMason

Source Repository - GitHub

For the current version of GeoMason, clone the MASON GitHub repository,

GeoMason has a dependency on the following Projects under MASON
You can find these in the above mentioned Source Repository


Current Version
geomason-1.6.jar (18M)

Older versions - JAR files

Installing GeoMason

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.

Install using Maven

Install using JAR files


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 the ShapeFileImporter and ShapeFileExporter classes, respectively. However, there is optional support via third party libraries for other data formats, which are described below.

GeoTools is a native Java library that offers support for reading a variety of geospatial vector formats including PostGIS and Web Feature Format. The GeoToolsImporter is 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.
GDAL supports a large number of raster geospatial formats including SDTS, DTED, GeoTIFF, and USGS Digital Orthophotoquad formats. Its sibling library, OGR, can handle an equally large number of vector formats such as SDTS, GML, TIGER, S57, KML and NTF. Accordingly, GeoMason offers optional classes that use these respective GDAL and OGR libraries, GDALImporter and 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.


The following archive contains data for the various GeoMason demo apps

GeoMason Examples

Included with GeoMason are several example models which you can run as:


Note that some of these models will require large data files. As mentioned above, they are located in jar files in (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 sim/app/data.

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 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.

Point Schelling 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.

Schelling Polygon

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.

Sick Students

This demo introduces a new agent-based model (ABM) for studying the spread of influenza through the schools and households of Fairfax County, VA. It is intended to explore the following questions. How does an epidemic outbreak spread through a school system? What containment approaches might be most effective at stopping an outbreak?


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.

SLEUTH: Urban Growth Model

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.

Water World

Inspired by NetLogo's Grand Canyon Model. The aim of the model is to show how data in the form of a elevation, can be used as a foundation of a simple spatial agent-based model. Similar to the Netlogo model, the elevation data comes from the National Elevation Dataset. It was converted from an ESRI Grid into an ASCII grid file using ArcGIS.

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 file but ensure you comment out the (e.g. add '//' ) to the following line:

// read landscape from file
landscape = setupLandscapeReadIn("elevation.txt");