Dynamic Bus Routing – PROGRESS

Current progress on the Urban Data Model (UDM) Platform and the Dynamic Bus Routing prototype. See the roadmap for the ongoing development of the UDM. Here is a video showing the current state of the simulation running.

The Dynamic Bus Routing prototype has now implemented the following feature:

  • loading of street network from a postgis database
  • bus traversal on the street network
  • definition of catchment zones based on Voronoi analysis of bus current route nodes
  • assignment of riders for pickup which fall into those zones
  • rerouting based on new rider pickup locations, and drop of locations once rider is picked up

Next steps include:

  • Fix the voronoi polygon union issue – current approach (polygon -> multipolygon) is fast but creates a bunch of strange boundary lines that are very distracting. Need to find a better solution for joining all the polygons to draw clean boundary lines between bus catchment zones!!!
  • Work on display layer issues, possibly using PGraphics objects to create multiple display “layers” – i.e. a UI layer on top, followed by an annotation layer, a draw layer, and finally a background layer on bottom.
  • Providing a rider handling system so that certain bus catchments don’t become too large (solving the problem that as more riders are assigned, the catchment becomes larger, causing more riders to be assigned, and so forth)
  • Build animation output
  • Providing some toggles for display styles
  • Add a UI library

UDM Progress

Basic UDM functionality up and running:

  • import from PostGIS database
  • data conversion from WKT to Geotools Geometry
  • scene geometry envelope calculation
  • view scaling and translation to extents of envelope
  • interactive zoom/pan with keyboard
  • interactive zoom/pan with mouse (need to disentangle this functionality from the main p5 App class using native Java mouseListener class)

Next steps:

  • clean up architecture of UObject package:  How to handle geometry in UObjects? Should UObjects be able to contain multiple geometries? Should all geometry draw functions be handled through inheritance of standard Geotools geometry objects – i.e. outside of UObjects?
  • Set up graph network layer – to what extent can Geotools classes be used/extended from here?
  • How to handle object display scaling issues with zoom functions?
  • migrate code to github
  • set up online PostGIS database and start testing remote access

UDM Roadmap

This is the preliminary class diagram for the UDM platform. The main goals in my mind in how this should be constructed is to make the structure as flat as possible, while still allowing it to be flexible to future changes and added complexity. This builds off the approach of Processing to create lean coding environments that are easily accessible to designers.


As the UDM is envisioned as a pedagogical tool as much as a design tool, its structure is intended as an introduction to basic Object Oriented programming (and design) paradigms. Key principles, such as inheritance, composition, “encapsulating what changes”, etc. are viewed as both as a way to ensure code reuseability and reconfigurability, as well as teaching tool for introducing and developing Object Oriented Design as an urban strategy – i.e. “Object Oriented Urbanism.” A key point of encapsulation includes the state objects, which define object behaviors, and ensure that any behavior can be reused, replaced and/or overlapped.

The UDM will be built with GeoTools library, which provides geometry types and the full functionality of a GIS platform.


Getting UDM up and running again

Starting to dust of the Urban Data Model (UDM) first started in the Research “Cloud” Studio I co-taught with Thomas Kearns at IIT in 2013-2014. This is a Java based platform, linked to a Post-GIS server, with the goal of providing a relatively user-friendly coding platform for mapping, simulating, and designing on/in/through geospatial city data at spatial and temporal scales not conventionally accessible to the designer. This respawn will be focused on improving existing functionality, swapping out some libraries, integrating new functionality and libraries, and starting to develop test cases.  The UDM is intended as both a design platform and a teaching tool for engaging students in computational thinking, object oriented design, platform based urban design, and critical cartography in the age of big data and <> cities.

Some key issues to be tackled:

  • Setting up a Postgres/PostGIS Server (Cloud-based?)
  • Getting the base code up and running in eclipse
  • Getting a GIT set up for future development
  • Removing the Igeo library graphics (too cumbersome) and using Processing for graphics
  • Developing a todo list of core functionality that should be added/improved

As a test case, the first prototype of this system will be an updated version of the dynamic bus routing system first developed in collaboration with students during the IIT cloud studio.

Previous version of the Dynamic Bus Routing illustrated the challenges of controlling the IGeo graphics (especially in terms of overlapping display geometry and transparency handling), as well as the complications due to the somewhat convoluted structure of the code – the result of rapid development during the school year. Here is a video of the DBR simulation from 2014 in action:

As a result of this experience, the goal here will be to build the system on Processing graphics and a simplified code structure, with a strong focus on building functionality (in static classes or otherwise) that will allow students and designers to focus on design thinking rather than basic platform infrastructure.

WORKPLAN (Test Case 01 – Dynamic Bus Routing Redux)

  • Set up local test PostGIS database, load test data tables (Chicago Street Center lines)
  • Build UDM DatabaseConnection
  • Build GeomConverter (from PostGIS DB -> UObject)
  • Build LayerManager, Layer Class, UObject Class
  • Establish camera controls (zoom to objects, switch between 2d and 3d views, etc.) – determine best Processing camera library – Peasycam, Proscene, OCD.
  • Draw street grid (as generic UObject)
  • Create necessary Data Tables (Street Grid, Census Blocks)
  • Create Street graph Layer
  • Network Utilities – shortest path (kdijkstra, etc.)
  • Create Rider Object + Rider Generator (Census Block)
  • Build Bus UObject
  • Text and visualize full ecology (animations, diagrams)


  • How structured should the code be? (with the goal of creating an easy to use library) Are UObjects a catch all (context, agents, etc)?