[Open-transport] Open Data Public Transport List?

[Pieter Colpaert]

Exactly my point as well. And we already have a CKAN for that at 
http://transport.datahub.io. Let's use that instance!

Kind regards,

Pieter

On 07/18/2013 03:45 PM, Stéphane Guidoin 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 
> <mailto: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 <mailto: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