The case for open source software

Releasing software as open source is LLNL’s default position when the content isn’t classified or controlled. That wasn’t always the case; the cultural shift took some time.

One common argument is relevance. Why do we deliberately produce software for public consumption? Because the potential for new discoveries and applications is too great to ignore.

The conclusion doesn’t just hold for open source and its relevance to scientific computing– parts of OneBusAway are running in every one of the transit apps that I’m aware of.

Via 18F Blog

What’s going on in Finland, Part I

This post is an introduction to several subsequent posts on a hot topic, Mobility as a Service (MaaS). It serves organize my thoughts on the matter, and we’ll return to the nerdiness soon.

In the US, the primary form of mobility is the private car. Most other options are controlled by multiple entities and it requires dedication to engage in a trip that connects across modes and providers. Planning a trip across different providers might now be integrated in an app, but being able to pay for that trip easily is still out of reach.  In some parts of the world, there are more options, but the bizarre set of factors that result in a travel mode choice are not the result of a rational equation, but a product of both habit and available information.

Enter Mobility as a Service (MaaS). Like other “as a service“ products, the value in the service is not in the monetary cost of the service, but in not needing to worry about the minutiae of setting up and managing the options that the service include. 

Imagine rather than having to worry about multiple websites / apps and multiple tickets each with their own restrictions on payment methods, a user pays for a certain amount of travel per month. This might be only a limited transit pass like that offered today. It might be a pass for transit region-wide. It even might include a certain amount of higher priced mobility services like ride-hailing or even airline tickets.

It’s been called “hotels.com for transport.”

When mobility is not essentially tied to a car, a cycle becomes possible. Being able to easily make trips without a car means that more trips will be made without a car. When car-free travel is unlocked as a choice, there are benefits that accrue— less space for roads, fewer deaths, less pollution, etc. 

The choices and the options we have we make form a Gordian knot, reinforcing each other, and breaking that knot is what MaaS is about. 

 

On Mobility and Choice

I believe that the ability to choose, and by extension the variation in choices based on changing circumstances, is a fundamental advantage. Transportation researchers, policy‐makers, and human resources administrators shape the way people make these choices. They make assumptions in the samples their models are based on, their policies, and their benefits packages about how we do behave, and how we should behave. These assumptions describe and affect the way we travel. Many of these assumptions are good, right and true, but one in particular is egregiously wrong. Many people in cities do not travel to work the same way every day. That is a myth. And the belief in this myth—as a simplifying assumption for modelers, and as a basis for government and employer transportation policies and subsidies—leads to inequitable outcomes and misguided policy choices. Decisions made based on this myth remove choices from citizens, and therefore make cities function less efficiently.

In urban areas many people have a choice of modes available for their activities on any given day. This includes their commute to work. These choices are manifest in the stories we tell each other…

David C Block-Schacter

An antescript to the subsequent post.

Examples of creating GTFS-rt from existing systems

There are several common methods of creating GTFS-rt from an existing system that does not support it out of the box. They typically depend on a system exposing good data, hopefully with trip assignment provided. This post outlines those methods and points to examples of implementation.

Continue reading “Examples of creating GTFS-rt from existing systems”

Mommy, what’s a Protobuf?

A question that continually pops up when someone learns that GTFS-Realtime is intended to be formatted as Protocol Buffers (or Protobuf) is, understandably, “why?”

The documentation does little to answer this question for laypeople.

“Protocol buffers are a language- and platform-neutral mechanism for serializing structured data (think XML, but smaller, faster, and simpler). The data structure is defined in a gtfs-realtime.proto file, which then is used to generate source code to easily read and write your structured data from and to a variety of data streams, using a variety of languages – e.g. Java, C++ or Python.”

What does that mean? Why not JSON (which is smaller, faster and simpler than XML)? I’ve heard a number of complaints that Protobuf is something along the lines of “entirely unnecessary.” But it’s not— it serves a purpose.

In short, Protobuf is designed to be:
* efficiently generated,
* efficiently transferred,
* efficiently processed (machine readable), and
* unambiguously understood by programs written in many languages.

Continue reading “Mommy, what’s a Protobuf?”

Pro Tip: Running FeedValidator and ScheduleViewer faster

The Google-supported transitfeed Python package includes several useful tools, including a Feed Validator and Schedule Viewer… But under Python they’re slow. With a moderately sized feed (Santa Clara VTA), it’s problematic:

python2.7 transitfeed-1.2.15/feedvalidator_googletransit.py vta/ > /dev/null
103.32s user 4.67s system 75% cpu 2:22.28 total

That took 103 seconds to run. Larger feeds take exponentially more time. What to do?

Enter pypy, a faster version of Python– written in Python. The differences are puzzling, but explained here. The same code run under pypy is much faster:

pypy transitfeed-1.2.15/feedvalidator_googletransit.py vta/ > /dev/null
30.48s user 3.05s system 74% cpu 44.928 total

30% of the time to do the same work.