[Open-transport] Open Data Public Transport List?
"GENDRE Pat - CETE Méditerr./DCEDI/DERIS/MIM"
Pat.Gendre at developpement-durable.gouv.fr
Thu Jul 18 13:51:28 UTC 2013
in case in might be useful, we maintain for the French ministry of
transport a directory of transport info services, where we try to update
info on open data and web services availability.
For open data :
For web service it is even more scarce (but we know we have are not )
This is not exhaustive and quite a work in progress but the description
of an individual data set or web service could be more detailed if needed.
Also, it is possible to create a account for people willing to take time
to this directory.
We proposed to the commission once in a while to have such a directory
at the EU level but I don't think it will be easy at the EU level.
mission Information Multimodale
(+33) 04 4224 7687
(+33) 06 2483 0349
Au 1er janvier 2014, les 8 CETE, le Certu, le Cetmef et le Sétra
fusionnent pour donner naissance au Cerema.
Le 18/07/2013 15:05, "> Andrew Byrd (par Internet, dépôt
open-transport-bounces at lists.okfn.org)" a écrit :
> 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.
> open-transport mailing list
> open-transport at lists.okfn.org
> Unsubscribe: http://lists.okfn.org/mailman/options/open-transport
More information about the open-transport