I have begun to map the routes that I know well using GoogleMaps and OpenStreetMap. Although it is fun to see the early products (amid a steep learning curve!), I am not yet ready to link them for a wide audience. If you would like a sneak preview, please communicate with me using the “reply” section of this post, or by contacting me through the feedback form of the “About” section of the blog.
The process of creating these early maps has caused me to see some challenges more clearly than at the outset. In the instances where my head was spinning with the details of routes, stops, and open mapping coding, I opted to more clearly identify these challenges in order to develop some foundational principles to guide the mapping process. These are subject to modification at any time, but will hopefully establish an architecture to make some early decisions easier.
Proposed nuts and bolts of mapping public transport in Lusaka
-The project must incorporate input from multiple individuals.
It would be an epic task for any one person to identify all of Lusaka’s public transit terminals, determine their destinations and ride all of the routes. Even if one did do this the resulting findings would not be sensitive to important time-of-day variations, nor the system’s frequent, yet usually unplanned, changes.
-Advanced technical skills must not be required
Incorporating feedback from multiple parties is an opportunity, but also a challenge; it requires a platform that is sufficiently straightforward and user-friendly to capture the relevant input without churning through people’s time and patience. Since I have only minimal technical skills myself, the need for simplicity has been established from the start.
-The mapping must be coherent with the logic of the system in Lusaka
Most maps of public transport are created to represent a system that has a pre-established logic as a system. This is not the case in Lusaka where the “system” is the sum total of the decisions made by individual drivers in response to the demands and preferences of riders. This does not mean, however, that public transport is complete anarchy; those decisions are made according to patterns that are created and re-created on a daily basis. This project aims to capture and represent those patterns, using the same logic that riders use to create the system demand, and that drivers use to respond to it.
-Capture sufficiently detailed information as to be useful
On the surface, the Lusaka’s public transport system is exceedingly simple: one can arrive at any destination to which a vehicle is headed (and nearly half of the time that destination is “Town”). The simplicity breaks down, however, when a rider tries to access a point that is mid-way between origin and destination since, 1) most stops have specific names that are not apparent to inexperienced riders, and 2) although the drivers, conductors, and riders have a very good idea of the route that the vehicle will take, they are not usually in a position to describe it well to someone unfamiliar with the terrain. Moreover, the drivers and conductors sometimes change the routing according to traffic conditions and the destinations of riders; these changes are also patterned, but require awareness on the part of riders in order to affect the decisions being made. This project will seek to incorporate sufficient information to allow a potential rider to figure out the places one can actually travel to, and account for variations that are foreseeable.
-Represent the most useful information in an easy-to-understand format
Representing a system simply can even be a challenge for public transit agencies that design their systems while considering simplicity. In Lusaka there is no design; so the challenge of capturing the variation and complexity, but finding ways to express the most relevant information simply, will be even greater.
Some of these issues have already emerged at this early stage; in particular the tension between capturing complexity and emphasizing simple and basic information. These could be scenarios where trade-offs are necessary, or ones where it is possible to simultaneously do both. In future posts I will outline some different options and the implications of each. Anyone hoping to be a part of this process at an earlier stage is, however, welcome to get in touch!