We are gradually supporting more and more cities. If your city has open public transport data and is missing, drop us a note. We will add it to navitia.io
The easiest is probably to jump to Examples below.
At some point you will want to read:
Our APIs are available at the following url: http://api.navitia.io.
Requests have the following structure : http://api.navitia.io/v0/[region/]api.format?arg=val.
Have a look at the examples below to learn what API we provide and how to use them.
The region can be left out for requests that are based on coordinates. The format is one of json, xml or pb (for a result in Protocol Buffers).
There are no restriction in using our API. However, please don’t make more than one request per second.
This API is experimental. The parameters and responses are not definite as we will listen to your feedbacks to improve it.
If you plan to build something successful, contact us to get an access with more vitamines and even more support.
Let us know if you build something with our API. We will be happy hilight it on this page. The more feedback we get, the more cities you will get and the more effort we will put to make the API durable.
This chapter shows some usages with the minimal required arguments. However, this is not a reference and not all APIs nor arguments are shown.
Let’s find out how to get from the view point of the Golden Gate bridge to the Transamerica Pyramid in San Francisco the 18th of April at 08:00 AM. We need to use the journeys API.
The coordinates of the view point are lon=-122.4752, lat=37.80826 and the coordinates of the Transamercia Pyramid are lon=-122.402770, lat=37.794682. The coordinates are always in decimal degrees as WGS84 (also known as GPS coordinates).
The arguments are the following:
A journeys request might return multiple journeys. Those journeys are said to be equivalent. For instance a journey can be faster than an other but requires more changes or more walking.
This API has more options explained in the reference as :
If you are wondering why the origin and destination have such a syntax, it’s because we allow to provide an address or a specific station as input. But we will see more about that later in the section about entry points.
The places API finds any object whose name matches the first letters of the query.
This API is fast enough to use it for autocompleting an user request.
The nearby_places API finds any object within a certain radius as a crow flies.
Only the coordinates an uri is mandatory. Optionally you can select what object types to return and change the radius. The URI must be a geographical coord or a stop point. Asking the stations arround a network doesnot make much sense. Does it?
All stations arround the Transamerica Pyramid can be fetched with the following request : http://api.navitia.io/v0/places_nearby.json?uri=coord:-122.402770:37.794682.
The isochrone API computes all routes from an origin to all stop points. Only the origin and datetime must be given.
Compared to the journeys API, only one result is returned for every stop point: the earliest arrival.
Here is an example url :
navitia allows to request the objects and filter them by an other object. Every object has his own API, but they all share the same filter argument. It is a very powerful requesting tool and its grammar is detailed in the The filter parameter section.
The results are paginated to avoid crashing your parser. The parameters to get the next page are within the result.
All available functions are documented on http://doc.navitia.io.
A mailing list is available to ask question : email@example.com
In order to report bug and make requests we created a github navitia project .
At last, we are present on IRC on the network Freenode, channel #navitia.
The street network is extracted from OpenStreetMap .
The public transport data are provided by networks that provide their timetables as open data.