Leicester Transit Agency

• 

  A sample trip

• 

  Map of the 4 routes

Inspiration

I was inspired by the hometown of HNTB's own representative, Nick LeBoeuf ! As an aside, I loved getting to know more about this town from Nick, apart from what I could find on the Internet for the creation of a transit system

What it does

The transit system covers all This app is a route planner ! As such, it'll take an origin and a destination, and it will compute the quickest route based on the constructed transit system's feed. If there are better alternatives given the particular time at which the route is requested, those will be presented as well

How we built it

Transit design

The design of the transit system was based off a modified hub-and-spoke model, which I might dub the "pizza slice" model. The town very clearly has two main roads that divide it into 4 quadrants like an xy-plane. Using those natural route guidelines, I decided to create two more routes that cut the town in half diagonally, one from the northwest to the southeast, and another from the northeast to the southwest. In this way, the routes form what could be considered the cuts made in order to slice a pizza into its typical 8 slice arrangement. The reasoning for this was to cut down on the initial, upfront cost when compared to the more traditional hub-and-spoke-model, as half as many routes are needed to service the same area. This transit system was then modeled using the General Transit Feed Specification (GTFS), which is a standard for representing the components of a transit system (routes, stops, trips, stop times, etc) in such a way that other tools can query (say, a route planner) in a standardized way.

Sample route (2, the Up - Down)

Given that the length of each route can be < 30 minutes, there are two opposing trips per route that take place every half an hour. For example, when considering route 2 of this system, which follows the road that splits the town in two vertically, this route conveniently named the Up - Down, one can expect a bus to start from the top of the route to make its way down, while a second bus starts at the bottom of the route and makes it way up, once at the hour mark, another at the half-hour mark. This is to provide consistent and predictable availability. Of course, an implementation of this system in real life would need to be paired with close monitoring to develop a better understanding of ridership distribution across the day, as this information is not available online

Technical implementation

In order to create a route planner, I used OpenTripPlanner (OTP), an open source backend that provides an API for client applications to query a GTFS feed. In addition to the route-representing feed, OpenStreetMap (OSM) data was needed for OTP to construct a network of roads for multi-modal route planning, so a subset of this global, collaborative map database was obtained using an OSM manipulation tool called Osmconvert. This is how the street data for Leicester was obtained. After propping up the OTP server with the appropriate data sources, a UI built using React.js and Redux was found called OTP-RR. It was properly configured, and then a Cloudflare tunnel was created to publicly expose both services.

Challenges we ran into

Leicester's small size made it a challenge to construct routes that could service the community in an appealing manner when car ownership is so common. It may still be one of the biggest difficulties with constructing a transit system for the town

On the technical side of things, the most difficult part was with the communication of the two services once exposed via the Cloudflare tunnel. I ran into an bug in which there was a protocol mismatch that was preventing communication. When this was resolved, I was stuck in a tricky situation because I couldn't figure out how to configure the UI to use properly authenticated HTTPS with the OTP server that was required by the eduroam network I was on. The insight here was to HTTPS up until the Cloudflare tunnel so that it satisfied the networks requirements from outside, while the ingress rule only used HTTP with the OTP server. The flow of communication looked something like this:

Browser -> HTTPS -> Cloudflare -> HTTPS -> Cloudflare Tunnel -> HTTP -> OTP Server

This allowed me to other details such as Java keystores and self-signed certs for the purposes of this presentation

Accomplishments that we're proud of

I'm proud of myself for having tackled a domain I've never set foot in before. I'm also proud of letting myself use software in a way that serves me, as I am known to succumb to the nitty-gritty of a product's technical implementation at the cost of the product itself.

What we learned

As my first attempt at the creation of a transit system, I had no clue how involved it would be to construct one, even for a town as small and neatly laid out as Leicester. One must consider everything from population demographics, traffic data, topography (eg. in the consideration of a bike sharing service as an additional mode of transport), its ability to integrate well with and complement existing services if there are any, traffic implications, initial vehicle investment, staffing, etc. This list goes on ! I also learned about the difficulties involved with this task for rural areas. Small distances, low ridership, staffing issues, stop placement, etc all make it difficult to present an economically viable system that the community can take advantage of

On the technical side of things, I learned about the rich community that exists around facilitating the development of such tools and applications.

• GTFS provides a way in which to represent or format transit systems, both more static feeds as well as more dynamic ones that rely on real-time information
• OSM is a collaborative, global map database that can be used to construct a network of roads for ingestion by tools such as...
• OTP, an open-source route planning backend that is built upon the two previous sources of data in order to create a foundation for route planning applications
• Osmium, Osmosis, Osmconvert, etc, are tools that can manipulate OSM data in order to best suite the needs of one's application. In my case, I used a web UI that wraps around one of these in order to crop New England OSM data for the town of Leicester
• GeoJSON, a JSON-based representation for a variety of geographic data structures (eg. the town boundaries of Leicester can be represented using this data format)
• Pelias, as a particular geocoder. Geocoders serve as the search engines of the Earth, capable of producing exact coordinates given the name of a place and vice versa. These two processes are called geocoding and reverse geocoding, respectively.

Lastly, I learned about Cloudflare tunneling in order to host the two services that come together to form this application !

What's next for Leicester Transit Agency

For the route planning app, I'd like to incorporate routes from the WRTA that service Leicester, which is the neighboring city's (Worcester) transit system. In particular, the 19 goes right through Main St, which cuts the town in half horizontally, and the 2 stops right at Worcester Regional Airport. I designed one of the routes of my transit system to share a stop with the 2, so that one could transfer over when headed to the airport. These connections with WRTA routes are not currently displayed in the app, so a future iteration of it would add that functionality.

As for the transit system itself, I'd like to consider the possibility of a bike sharing service like that of the Bluebikes in Boston ! A few considerations for such a service are as follows.

In favor of it:

• Encouragement of physical activity
• Feasible for getting around given the town's small size
• Leicester makes for a beautiful town to bike around in

Against it:

• Roads in Leicester are not terribly bike friendly. Main St in particular has a stretch on the western half of Leicester in which cars oftentimes reach speeds of ~50 mph. This could present safety concerns
• The topography of the northwestern quadrant is rather hilly

Both ?

• Leicester has an older population, with a median age of 42. On one hand, encouragement of physical activity in such a population would definitely improve resident well-being. On the other though, the safety concerns and physical exertion required to go through certain parts of the town might not be best suited for Leicester's population

Built With

• gtfs
• opentripplanner
• osmconvert
• pelias