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

New York Times Geographies

The folks at New York Times infographics department have found and made great use of another extraordinary dataset:

This map was generated from a new data-set of 125 million buildings created by Microsoft and released open source on OpenStreetMap. The data was created using the CNTK Unified Toolkit, an open-source machine learning library that analysed satellite imagery to trace and then polygonize building footprints.

The approach to generating this data brings up issues of accuracy and validation.  The Nytimes mappers address this to some degree, discussing how they addressed inaccurate tracing of building footprints by replacing areas where better data was available. This approach of validating across multiple data sets is of course an essential part of geodata modeling, and something we often discussed with students – part of the broader “author your own data” initiative, which encourages the interrogation of existing data, and the generation of new data on the ground as a way to take ownership of the regimes of data production and visualization, and the agency derived therein.

What is perhaps most interesting here is the ways computer vision takes on an increasing function in the interpretation – and design – of the world, as computational systesms are endowed with the ability to “sense the world and learn to think” (to paraphrase Ben Bratton). What does it mean to design objects (buildings or otherwise) that respond not just to the human visual sensitivity, but also to computational visual biases? Will driverless car visioning make us rethink Kevin Lynch’s characteristics of a “well imaged city”? Will building footprints and the figure-ground relationships of the city be transformed through the   eye of OpenStreetMap’s all seeing and now all drawing eye? What do urban features – building, parks, cars, benches, trees, etc. look like to an AI vision system – and will these non-human “aesthetics” have any impact on how objects are designed?

On another note, another great post from Derek Watkins from the NYTimes discussing the challenges and computational approaches involved in displaying super-high resolution simulations of Antarctic ice flows with web motion graphics:




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)?

Dynamic Bus Routing

Examples of the simulation of a dynamic bus routing system running on the streets of Chicago. Work completed by Profs. Thomas Kearns + Jordan Kanter and students Adam Weissert, Haidong Fei, and Li Gong as part of the Urban Data Model Prototype Studio at IIT in 2013-2014.

whiteboard systems diagram: interaction of bus, rider, and street network objects in simulation

bus routing diagram: indicating the process of describing catchment zones based on an updated voronoi diagram of current bus route to determine which bus in the system to assign a new pick-up to and thus rerouting the buses

process for generating riders (pickup location + destination) based on analysis of demographic data


process of assigning weighted lengths for each edge in the street graph based on various city data and spatial inputs: number of street trees, sidewalk widths, pothole complaints, expected ridership, etc.