[Open-transport] Open Data Public Transport List?

Thu Jul 18 16:18:35 UTC 2013

Pfft! Really guys, why not just create an account on
http://transport.datahub.io and add some better meta-data over there? We
are going to do duplicated work if we start using the google drive document
at first.

I'm not going to be the one who harvests this list into CKAN and adds
missing meta-data.

http://transport.datahub.io

Do it.

NOW ;-)

Pieter

On Thu, Jul 18, 2013 at 5:15 PM, Mati Kalwill <matias.kalwill at gmail.com>wrote:

> I believe Patrick's invitation to create a open, editable list of Open
> Data Transport to be very useful. We've recently launched the OKNF group in
> Argentina and this issue came up - *what is being used right now por open
> data in transport*?
>
> A clear picture of *what is out there* is a necessary step towards facing
> the challenges pointed in this thread with Open Transport Data . A simple
> way to share this information seems like a great way to start. Of course if
> the list grows it would be usefull to move it into a better-crafted
> environment like the CKAN install, but why not start here? Simple, open and
> take it from there when it grows.
>
> Thanks for the kickstarting the doc Rufus! Here's the link again in case
> anyone missed it.
> https://docs.google.com/spreadsheet/ccc?key=0AqR8dXc6Ji4JdHlCTXhkeTlvSm1qS1RwZjRBUk1aemc#gid=0
>
> Count me in for some edits.
>
> Best,
>
> Matias Kalwill
> @matikalwill
>
>
> On Thu, Jul 18, 2013 at 11:21 AM, Pieter Colpaert <
> pieter.colpaert at okfn.org> wrote:
>
>> 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 <open-transport at lists.okfn.org>>
>>>
>>>     http://lists.okfn.org/mailman/**listinfo/open-transport<http://lists.okfn.org/mailman/listinfo/open-transport>
>>>     Unsubscribe: http://lists.okfn.org/mailman/**options/open-transport<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<http://lists.okfn.org/mailman/listinfo/open-transport>
>>> Unsubscribe: http://lists.okfn.org/mailman/**options/open-transport<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<http://lists.okfn.org/mailman/listinfo/open-transport>
>> Unsubscribe: http://lists.okfn.org/mailman/**options/open-transport<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/25a9e342/attachment.html>