Unraveling the Transit Fabric

Previous efforts of privatizing Dutch rail failed miserably. In 1999 Lovers Rail ran competing trains along a couple of Dutch tracks1. I was just starting my studies in Delft and did a daily commute from Amsterdam where I was living back then2, so I remember their service, though I never actually used it.

Full Train

Sometimes when stuck on a station, because the NS had messed up again, it could actually have been useful to take a Lovers train from Haarlem to Amsterdam. In reality this never worked out. Nobody knew when those trains actually departed and where to buy tickets for them3.

The privatization was stalled and the NS was granted a monopoly on the main rail system until 2015. Now if we want to be in good shape to turn another privatization attempt into a success by then or hopefully before, we had better get our digital infrastructure in order.


I think two ingredients are now slowly getting into place to turn another privatization attempt of the railways into a success:

  1. Full dynamic and open transit data
  2. Seamless transit payment

OV-chipkaart terminal
CC picture by mooste

Neither of these is fully there yet4, but in a couple of years we may expect both deployments to mature significantly. In that future perfect you will always know which train will take you to your destination regardless of the operator who runs the service. Payment of that service should be as easy as the check-in, check-out system of the OV-chipkaart right now if not easier.

Rail services would then finally be completely commoditized5 and by extension we could do the same to all of transit.

Breaking it open

Rail is one thing, but the transit experience entails the door to door planning and execution of a trip of which rail is just one part. Data and payment are just as essential to a nationwide6 transit infrastructure. Probably even more so because of the greater diversity of transit providers7, many of which are not bound to fixed rail.

For my day to day transportation needs I want to get from A to B at a certain time for a certain price. A mobile device would know my location and when given my destination it would be able to show me a list of offers from which I could pick my preferred one. Some of the planners available do just this but because they are usually limited to a single operator, their offerings do not differ much.

9292ov.nl: OV-reisinformatie en routeplanner voor bus, trein, metro, tram en veerboot

Google goes for a more modus agnostic integrated and modern view of the experience:

Google Transit

Further opening up and integration would benefit travellers enormously. Ideally we would have one planner for all transit options, which includes rail, (micro)bus, lightrail, ferry but ideally also taxicabs and private individuals willing to carpool8. This would add options and level the playing field.

What we would need

The following data dimensions would influence your choice of transportation option and would need to be offered to you by your planning tool of choice:

Time: How fast will this get me somewhere? How long do I have to wait before it leaves? Or did it already leave? How many times do I need to change?

Money: How much does this trip cost me? How much does it cost me in terms of CO2? Is it offset? How much would it cost me (in time and money) if I’d taken my car instead?

Quality: What is the quality of service offered? Are there different classes with different amenities? Is there WiFi on board? Do I get assistence getting on/off or with my luggage?
These would probably be standardized per modus of transportation but the class separation is pretty ingrained and influences the cost.

Reviews: What do people think of this particular operator?
In the case of standardized operators, you will usually know what you will get, but especially useful for modi where there is a great variety of operators performing services. Taxicabs would be a very nice target for community judgement.

Of course you should be able to set your preferences as to which modi and operators to prefer and which to never take unless no other options are available. Complicated but also a very nice UX problem to solve.

Planning and Negotiation

Some extra functionality may also be interesting to incorporate in this dynamic transit fabric:

Planning: Submitting a tentative plan may be interesting for transit operators so that they can optimize their services ahead of time. Many commuters know when they will travel which route a year or so in advance sometimes. Marginal discounts may be offered to those who submit a plan and stick to it (penalties for those who deviate)9. Publishing the statistics of trips requested and trips completed would show over- and undercapacity and give the various operators the chance to adjust their offerings.

Submitting a plan may involve a negotiation step: e.g. it will be cheaper if you walk to a certain place (stop) or the bus will swerve round to pick you up for a couple extra euros, which do you prefer?

A plan would then need to be finalized, either at the point of getting on/off (and paying the fare amount) or ahead of time to reserve a (type of) seat in a vehicle or for remote locations to guarantee the fact that the vehicle will pass by your area at all.

Renegotiation: Changes do happen, most impactful are those due to calamities: vehicle failure, track obstruction. Being able to flexibly catch these will vastly improve the transit experience10. A good system would both inform transit operators so they can allocate extra resources where suitable and help travellers replan their journey in light of changed circumstances.

In a dynamic system with the planning functionality as described above in place, others’ change of plans in the system may influence your journey but no more than a couple of minutes. What would happen when those changes propagate through the entire network?


If we could achieve the openness and added integration of more information and more transit providers described above we could make very satisfying complete transit experiences.

iPhone Transit Planner

I’ve made a mockup what such an application could look like:

Being able to compare and contrast various transit options would of course be fantastic, but that isn’t so far off anymore. For me the most promising idea is to provide the information and the incentives to enable the transit problem to be made transparent and to be crowd-sourced.

  1. Among which Amsterdam — Haarlem, also the oldest Dutch railway connection.
  2. And where I will be living again in the near future if things work out.
  3. Of course you couldn’t buy tickets on board.
  4. For a Dutch argument see a previous post.
  5. This is assuming ProRail would be able to cope with the complexity of accomodating for all these operators.
  6. We could also think about the transnational problem but let’s leave that for now.
  7. And the Netherlands has one of the finest transit meshes in the world. We would be stupid not to take advantage of that.
  8. Just think how disruptive this would be to the whole concept of transit.
  9. Of course this will completely cloud the pricing structure of transit. I’d be fine with it. It’s mostly voodoo to me anyway already (never really figured out the relation between strippen and zones).
  10. Though people may not notice. Failure is annoying when it happens but quickly forgotten. A system which resolves not to fail may set itself up to impossibly high standards.

10 thoughts on “Unraveling the Transit Fabric”

  1. Alper, this was a very interesting post. In terms of getting started on this agenda right now I think opening up transit data and incorporating additional forms of transit are the low hanging fruit.

    I think it’s wrong that 9292ov, essentially a public service, is run like (actually as?) a for profit company. This approach leads them, for instance, to not make their database of public transport information readily available, which I know has created problems for mashup developers.

    As for additional forms of transit, I would imagine that that it shouldn’t be _too_ hard to plug into taxi companies’ dispatching services and carpooling services like Karzoo.nl.

  2. Thanks, and cool!

    Yeah, I think the amount of waste currently in this domain is staggering. Just pushing the data into Google Transit would hugely enable my iPhone to do some very cool things.

    An agenda and a campaign are necessary. In 5 years we’ll all have GPS enabled phones (among other devices) and we can brute force the problem, but I’d rather we didn’t have to wait and didn’t have to go that far.

    I didn’t know Karzoo.nl existed (I wanted to build this). The execution looks fine, but the site is pretty much dead.

  3. Good stuff, Alper. One minor point: you’re making the case for seamless payment, and I know what you mean by that, but at the same time, I think you’d want payment to be seamful, right?

    What’s that about moving to AMS though, I thought you were going to come to Utrecht? 😉

  4. The link you point to gives me a ton of academia but no workable definition of seamful. I get your point though —I think— but if you could expose more on the subject it might be useful. I don’t think it helps discourse if the both of us say: “We think we know what we both mean.”

    I got an offer to move to AMS with a friend. If you have an offer in Utrecht, I’ll put it forward, but I think my friend will be a hard sell.

  5. I think this post by Adam Greenfield towards the end summarizes most of what I was thinking when I commented earlier:

    “This term was coined by the late Mark Weiser, a pioneer of ubiquitous computing and the Chief Technologist at what was at the time the Xerox Palo Alto Research Center. Instead of the discourse of smooth, distinction-obliterating, disempowering seamlessness which was then (and is to a significant degree still) dominant in discussions of ubiquitous information processing systems, Weiser wanted to offer users ways to reach into and configure the systems they encountered; ideally, such seams would afford moments of pleasure, revelation and beauty.”

    The whole thing is worth a read, by the way, if you haven’t already.

  6. Great thoughts!

    It pops in my mind what would happen if the whole model of scheduled transport is replaced with incremental transport. Where we can catch the positions of all specific vehicles out of the cloud and calculate the real journeys… Seamless 😉

    But that would not easy to monopolize so we will probably have to live with the delayed model for some time…

  7. @Iskander, Like packet switching on the internet? Once we achieve the fluidity I describe above, we could then see if it would be indeed more efficient to build up transport incrementally in an ad-hoc fashion and we would also have the JIT information to be able to implement such a system.

  8. @Kars: I’ve read it a while back and I get that seams are the points to design for.

    Regarding payment in transit like I described above: the system should show you what you are paying for and how much, it should show you alternatives and it even should let you opt out of the system completely if you so wish (I can imagine paper tickets being in use indefinitely for a very small minority).

    But when I’m in a hurry or busy and I don’t want to be bothered with any of this stuff, yes it should be seamless.

  9. This is an excellent post! I’ve had the idea for open public transportinformation for some time now. To be honest, the 9292 information is quite good compared to information in other countries but mobile sites and applications could just be so much more innovative. I understand from a business perspective, the transport companies want to control the information; that’s why I hope the politicians (specifically: consessiehouders) that largely control the funding, can be a facilitator here.

  10. Thanks, do you have more info on the various concessiehouders in the Netherlands?

    We could lobby them and see if we can persuade them. I’ve pretty much given up on our transit providers doing anything except serve vested interests.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.