[Open-transport] Open Data Public Transport List?

Thu Jul 18 13:45:35 UTC 2013

In think that the initial point of Patrick was: let's build something like
GTFS-exchange but format-agnostic (raw & APIs). I tend to agree since have
a portrait of who is doing what (publishing/not publishing, using
GTFS,Netex, custom, whatever) is useful to help potential consumer to
understand what's going and to help advocates to build pros/cons.

---

Just a comment about the API discussion

Why using an API:
1. You can analyse what people are doing: what type of data they are
calling, how frequently. Gives you a sense of "how much useful" the data is
2. Usually with an API, you have to register to the publisher has a way to
contact the users. With the use of a key, you can also know who is doing
what, you can profile your users. Registration can be optional like what
BART is doing, but in the end a large part of the users are registering
because it is a great way to establish a community & to have
bi-directionnal communication. Organizations like Mashery are also
promoting a lot "profiling" of the user... and in the end, manage API users
like one could manager regular clients (that's what Twitter has been doing
since the beginning). As Andrew said, profile might lead to monetization...
3. Obviously, you can cut anybody's access when you are not happy with what
they are doing with the data...

Now it does not mean that everything fits for an API. Large and mainly
static data where the consumer needs to get all the data in order to work
will not work with an API approach. On the other hand real-time data does
fit with API (I know sounds obvious).

On Thu, Jul 18, 2013 at 9:05 AM, Andrew Byrd <andrew at fastmail.net> wrote:

> 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
>
> _______________________________________________
> open-transport mailing list
> open-transport at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/open-transport
> Unsubscribe: http://lists.okfn.org/mailman/options/open-transport
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/open-transport/attachments/20130718/491eebc9/attachment.html>