[Open-transport] Open Data Public Transport List?

Thu Jul 18 13:05:53 UTC 2013

On 07/18/2013 02:01 PM, Stefan de Konink wrote:
>> 1) It would allow the open data community to see which APIs are most
>> used. If someone is considering writing a converter between one API to
>> another, the developer could see which regions would be covered and
>> which APIs the developer can test against.
> 
> Could you please elaborate why interopability between API's from
> different regions is important. You seem te advocate that open data
> public transport is something like building a view on an existing
> system. While what most transit developers require is the freedom to
> have access to the raw data behind it.

I think we are just experiencing a vocabulary mismatch. I believe
Patrick is suggesting that we catalog which bulk data formats are in use
by which agencies.

Some context: The reason APIs versus bulk data is a sensitive subject is
that many operators (specifically large rail operators or regional
authorities) absolutely do not want to release raw data because 1. they
want to monetize access to that data and 2. they fear irrelevancy when
faced with independent developers' products (a concern not supported by
real world experience e.g. in London). In order to respond to growing
public pressure to "be open" they strongly advocate "open" APIs rather
than delivering bulk/raw data, and push for federated routing and
information systems that compose queries to regional transport data APIs
built on closed data.

This position makes little technical sense. It is founded on an outdated
understanding of journey planners as giant unwieldy things running on
mainframes, requiring vast amounts of data that couldn't possibly be
brought together all in one place. It is true that journey planning
requires a lot of calculation and a lot of data, but processing speeds,
data storage capacity and bandwidth have been increasing very rapidly
for decades.

The truth of the matter is that in 2013 you could probably produce a
decent trans-continental journey plan on a typical smartphone without
even using a web API (i.e. calculate everything on the phone).

>From an algorithmic perspective, it's a pain to properly optimize an
itinerary if you don't have all the information locally; you either have
to make a lot of guesses or produce a ton of network traffic. Also,
consider the one-to-many or many-to-many cases common in research and
planning work (yes, public transport data are useful for many other
things besides passenger information). An operation that would require
millions of individual requests to a point-to-point journey planning
APIs might only require a single search if we have the data locally.

-Andrew