[Open-transport] Open Data Public Transport List?

Thu Jul 18 14:03:02 UTC 2013

I prefer bulk access to real-time data is critical as well.  APIs are great
for "what are the next three buses arriving at this stop" but not so good
if I want to build a real-time trip planner, for example.

On Thu, Jul 18, 2013 at 3:45 PM, Stéphane Guidoin <stephane at opennorth.ca>wrote:

> 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
>>
>
>
>
> _______________________________________________
> 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/812730c3/attachment.html>