opendatach / transport Goto Github PK

Hello Transport CH community.
In my search to see if there is API access to the train ticket price database in CH I have come across this project and working group. My goal in this is as follows:
I am a DE (Designated Expert) for Zurich and Switzerland on the web Forums of "Trip Advisor". On these Forums we try to help travelers with queries about traveling in Switzerland. This is volunteer work - this is not a job or commercial enterprise in any way!
One of the most common questions for visitors to Switzerland is - "Tickets or train pass".
Because the answer to this question is highly subjective dependent on the travel choices, dates, and options the visitor is making, there is no easy clear answer - other than to suggest to the OP to do the math themselves.
I have been thinking that - if one had access to the SBB TICKET COST data - then writing a small calculator app (or even an excel spreadsheet with lookup) would be relatively (somewhat?) straightforward. I see that the "Transport" project has accessed the TIMETABLE data, but do you know if there is an API to access the ticket cost data?
The volunteers who offer advice on Trip Advisor are not (in any way!) programmers or technical people. I myself have some (weak and limited!) scripting experience, so my goal is to figure out if the data is available, easy to integrate into an app, webpage, or other tool - and then to decide if this is a project that is worth pursuing in the long term.
If anyone has any insight or advice about this topic and access to this data I would be appreciative.
With thanks - Alex.

I'd like to be able to integrate the API right into a web client. We're working on a Sencha Touch application that has no server component. Still, we'd like to use the transport API.

Due to the same origin policy the only two options right now are either to run a reverse proxy which forwards requests to http://transport.opendata.ch/v1 or to run our own transport server (which we do now).

Request: allow for client-side integration (i.e. AJAX) of the transport API through JSONP and/or CORS.

http://enable-cors.org/
http://nelm.io/blog/2011/11/cors-with-sencha-touch/

Support "via" arguments.

Have the travel duration returned in the connection object.

C'est possible d'ouvrir le wiki? Merci

The debug mode is currently hard coded and set to 'true'.

I recommend setting the debug mode to false and check against a certain environment variable and enable the debug mode only, if this environment is set.
Easiest way:
Add line to .htaccess
SetEnv APPLICATION_ENV debug

$debugMode = getenv('APPLICATION_ENV') === 'debug' : true : false;

Try searching the connection "Zürich Brunau" to "Wetzikon, Spital". On the SBB website, you can see the (aggregated) occupancy. In the connection response from the API, the values are null.

Would be great if the API could handle this issue, instead of all implementations having to aggregate the sections' prognosis.

I wrote a short script showing the next connections for a certain station, e.g. Zurich. For tramways, I added a switch-case which sets the color of the corresponding VBZ line. Since a few days, the operators field in the API return is always empty / null.
Is that a bug or rather a feature? ;-)

http://localhost/transport/web/api.php/v1/connections?from=bern&to=z%C3%BCrich&date=2012-04-08&time=18:40&limit=4

This returns 5 connections instead of 4.

I have a problem with my api.php
I geht the following Errors:
Warning: require(C:\htdocs\transport_lib\web/../vendor/autoload.php): failed to open stream: No such file or directory in C:\htdocs\transport_lib\web\api.php on line 3

Fatal error: require(): Failed opening required 'C:\htdocs\transport_lib\web/../vendor/autoload.php' (include_path='.;C:\php\pear') in C:\htdocs\transport_lib\web\api.php on line 3

could you maybe fix this?

I though I fixed this issue with this commit: 69f7205 , but this issue with adding 1 day actually still persists in one situation:

The problem arises when the train departure is delayed. It seems that SBB returns the scheduled departure time, and it could be any time in the past. Don't know how to fix it at the moment.

/v1/connections?from=Fribourg, grand-rue 31&to=lausanne&limit=6

Fatal error: Call to undefined method Transport\Entity\Location\Address::toXml() in Sites-src/transport.dev/lib/Transport/Entity/Schedule/ConnectionQuery.php on line 75

Call Stack:
    0.0002     639688   1. {main}() Sites-src/transport.dev/web/api.php:0
    1.2627    1270024   2. Silex\Application->run() Sites-src/transport.dev/web/api.php:214
    1.2636    1416968   3. Silex\Application->handle() phar://Sites-src/transport.dev/silex.phar/src/Silex/Application.php:396
    1.2646    1459368   4. Symfony\Component\HttpKernel\HttpKernel->handle() phar://Sites-src/transport.dev/silex.phar/src/Silex/Application.php:411
    1.2646    1459368   5. Symfony\Component\HttpKernel\HttpKernel->handleRaw() phar://Sites-src/transport.dev/silex.phar/vendor/symfony/http-kernel/Symfony/Component/HttpKernel/HttpKernel.php:72
    1.2668    1555848   6. call_user_func_array() phar://Sites-src/transport.dev/silex.phar/vendor/symfony/http-kernel/Symfony/Component/HttpKernel/HttpKernel.php:128
    1.2668    1556184   7. {closure}() phar://Sites-src/transport.dev/silex.phar/vendor/symfony/http-kernel/Symfony/Component/HttpKernel/HttpKernel.php:128
    1.6391    1743440   8. Transport\API->findConnections() Sites-src/transport.dev/web/api.php:161
    1.6391    1743440   9. Transport\API->sendQuery() Sites-src/transport.dev/lib/Transport/API.php:64
    1.6391    1744344  10. Transport\Entity\Schedule\ConnectionQuery->toXml() Sites-src/transport.dev/lib/Transport/API.php:55

I use the patch from #61

What is a stationboard ressource? It's all connections from one station. We can even think we have arrival station board than is all connection arriving to a station.

http://transport.opendata.ch/v1/connections?from=Zurich HB

Is the same than

http://transport.opendata.ch/v1/stationboard?station=Zurich HB

And the departure station board can be found like

http://transport.opendata.ch/v1/connections?to=Zurich HB

I think we should remove the stationboard from the API. For the station resource make "from" and "to" parameters optional.

Agree on that?

limit=6
http://transport.opendata.ch/v1/connections?from=lausanne&to=fribourg&limit=6 works

limit=8
http://transport.opendata.ch/v1/connections?from=lausanne&to=fribourg&limit=8 fail with "Invalid value for Parameter limit."

It's Monday 2nd April 2012 00:20 right now and when I make a call to the stationtable thats the response:

http://transport.opendata.ch/v1/stationboard?id=008591341

{
stationboard: [
{
stop: {
station: {
id: "8591341",
name: "Zürich, Schmiede Wiedikon",
score: null,
coordinate: {
type: "WGS84",
x: 8.519122,
y: 47.370446
}
},
arrival: null,
departure: "2012-04-03T00:18:00+02:00",
platform: "",
prognosis: {
platform: null,
time: null,
capacity1st: "-1",
capacity2nd: "-1"
}
},
name: "Tram 14",
category: "Tram",
number: "14",
operator: "VBZ",
to: "Zürich, Seebach"
},

as you can see the date is wrong, it shows the date for tomorrow 3rd April.

As the xsd linked in the responses from xmlfahrplan is not available anymore i created a gist with a version i captured when it was still online some months ago.

https://gist.github.com/2309851

There are 6 Legs for an example connection between Effretikon, Eselriet and Stadel b. N., Stig.

Currently a connection looks like this:

    {
        "date": "2012-03-31", 
        "from": {
            "arrival": null, 
            "departure": "23:34:00", 
            ...
        }, 
        "to": {
            "arrival": "01d00:33:00", 
            "departure": null, 
            ...
        }
    }, 

By the principle of least surprise, it would make more sense to put the date in the for and to objects and remove the offset from the arrival time.

    {
        "from": {
            "date": "2012-03-31",
            "arrival": null, 
            "departure": "23:34:00", 
            ...
        }, 
        "to": {
            "date": "2012-04-01",
            "arrival": "00:33:00", 
            "departure": null, 
            ...
        }
    }, 

In the stats view the labels of the y-axis have a small CSS issue, "14000" is displayed as "140" only.

See #46

Is there any possibility to get the departing trains for a specific time?

Reproduce: http://transport.opendata.ch/v1/locations?query=Maienfeld%20%2CPost

Since today morning I recieve the following error after querying for "Maienfeld, Post":

Fatal error: Uncaught exception 'Predis\Connection\ConnectionException' with message 'Connection refused' in /var/www/vendor/predis/predis/lib/Predis/Connection/AbstractConnection.php:146 Stack trace:

/var/www/vendor/predis/predis/lib/Predis/Connection/StreamConnection.php(96): Predis\Connection\AbstractConnection->onConnectionError('Connection refu...', 111)

/var/www/vendor/predis/predis/lib/Predis/Connection/StreamConnection.php(70): Predis\Connection\StreamConnection->tcpStreamInitializer(Object(Predis\ConnectionParameters)) #2 /var/www/vendor/predis/predis/lib/Predis/Connection/AbstractConnection.php(96): Predis\Connection\StreamConnection->createResource()

/var/www/vendor/predis/predis/lib/Predis/Connection/StreamConnection.php(141): Predis\Connection\AbstractConnection->connect()

/var/www/vendor/predis/predis/lib/Predis/Client.php(152): Predis\Connection\StreamConnection->connect()

/var/www/web/api.php(52): Predis\Client->connect()

{main} thrown in /var/www/vendor/predis/predis/lib/Predis/Connection/AbstractConnection.php on line 146

Afin d'améliorer le wrapper. Ici une capture que j'ai effectuer de l'API des CFF. C'est moche :).

https://gist.github.com/2019386

https://twitter.com/#!/cedricmoullet/status/185663630732296192

Have nearby station search return the distance between the submitted location (x,y) and the found stations in Meters

x/y are supposed to represent lat/long. This works fine for the URL parameters. However, in the result set x represents long and vice versa.

Example: http://transport.opendata.ch/v1/locations?x=47.1795&y=8.00459

{"stations":[{"id":"8502006","name":"Wauwil","score":null,"coordinate":{"type":"WGS84","x":8.019016,"y":47.183848},"distance":1192.7},{"id":"8582442","name":"Wauwil, Zentrum","score":null,"coordinate":{"type":"WGS84","x":8.019483,"y":47.184837},"distance":1272.4},....

Just noticed that it's actually coming back that way from Hafas. This is the request submitted:
http://fahrplan.sbb.ch/bin/query.exe/dny?performLocating=2&tpl=stop2json&look_maxno=10&look_stopclass=1023&look_maxdist=5000&look_y=47043989&look_x=8465647
Here's what's coming back:

{ prods:"1023",
stops:
[
{
x : "8466696",
y : "47044003",
extId:"8505074",
puic:"95",
name : "Rigi Kaltbad-First",
prodclass : "32",
urlname : "Rigi%20Kaltbad-First"
}
,

I guess in order to fix this in a future-proof way (that is until Hafas fixes this) you'd have to check whether y > x then invert and skip otherwise.

So I'm not a map guy.. but this is what I get from https://twitter.com/#!/cedricmoullet and remember now.

The return coordinate doesn't look like WGS84 but more like http://wiki.openstreetmap.org/wiki/EPSG:3857 with a lost comma.

So we should return

...
  "coordinate": {
                "type": "EPSG:3857",
                "lon": "8.540192",
                "lat": "47.378177"
            },

Instead of

...
  "coordinate": {
                "type": "WGS84",
                "x": "8540192",
                "y": "47378177"
            },

If someone can confirm this it would be great :).

The following request /v1/connections?date=2012-04-16&to=Zürich&from=Chiasso&time=20%3A00 throws an error

Catchable fatal error: Argument 2 passed to Transport\Entity\Schedule\Prognosis::createFromXml() must be an instance of DateTime, null given, called in [...] /transport/lib/Transport/Entity/Schedule/Stop.php on line 72 and defined in [...] transport/lib/Transport/Entity/Schedule/Prognosis.php on line 13

I verified on prosurf.sbb.ch that there at the time of the reuqest, there was a train from Chiasso to Zürich which had a slight delay. Trains with no delays worked fine.

My PHP knowledge is not good enough, so I can't suggest any fixes. Where can I log the result of the original XML request?

Thanks
Stephan

Strangely, no stations are returned from this coordinates:
http://transport.opendata.ch/v1/locations?x=46.77867&y=6.638251, which is almost the center of Yverdon-les-Bains, but slight changes to the coordinates (http://transport.opendata.ch/v1/locations?x=46.77867&y=6.641041) make everything work properly.

Need documentation for this: #39

There is a problem with multiple connections where I get a network error. E.g. everytime I try to get connections from "Bern" to "Basel" or "Zurich" to "Bern", the request fails and I get a "500 Internal Server Error" response.

The dateType for the ConnectionQuery should be exposed. This is mentioned in issue #47. Currently it is hard coded to be a departure time.
How should this be exposed. I think a dateType variable which can be set to 1 or 0 is not as clear as it should be.
What about isDepartureTime?

/stationboard has a limit param but for connections you always get 5 connection. Would be nice to control how many connection we want.

When I make a request shortly before the end of the "Betriebszeiten" from the SBB, it gives me only departures for the current "Betriebstag", could you extend it, that it also shows departures for the next day?

Request: http://transport.opendata.ch/v1/stationboard?id=008591341 on 00:20
response:

{
stationboard: [
{
stop: {
station: {
id: "8591341",
name: "Zürich, Schmiede Wiedikon",
score: null,
coordinate: {
type: "WGS84",
x: 8.519122,
y: 47.370446
}
},
arrival: null,
departure: "2012-04-03T00:18:00+02:00",
platform: "",
prognosis: {
platform: null,
time: null,
capacity1st: "-1",
capacity2nd: "-1"
}
},
name: "Tram 14",
category: "Tram",
number: "14",
operator: "VBZ",
to: "Zürich, Seebach"
},
{
stop: {
station: {
id: "8591341",
name: "Zürich, Schmiede Wiedikon",
score: null,
coordinate: {
type: "WGS84",
x: 8.519122,
y: 47.370446
}
},
arrival: null,
departure: "2012-04-03T00:19:00+02:00",
platform: "",
prognosis: {
platform: null,
time: null,
capacity1st: "-1",
capacity2nd: "-1"
}
},
name: "Tro 33",
category: "Tro",
number: "33",
operator: "VBZ",
to: "Zürich, Morgental"
},
{
stop: {
station: {
id: "8591341",
name: "Zürich, Schmiede Wiedikon",
score: null,
coordinate: {
type: "WGS84",
x: 8.519122,
y: 47.370446
}
},
arrival: null,
departure: "2012-04-03T00:21:00+02:00",
platform: "",
prognosis: {
platform: null,
time: null,
capacity1st: "-1",
capacity2nd: "-1"
}
},
name: "Tram 14",
category: "Tram",
number: "14",
operator: "VBZ",
to: "Zürich, Sternen Oerlikon"
},
{
stop: {
station: {
id: "8591341",
name: "Zürich, Schmiede Wiedikon",
score: null,
coordinate: {
type: "WGS84",
x: 8.519122,
y: 47.370446
}
},
arrival: null,
departure: "2012-04-03T00:23:00+02:00",
platform: "",
prognosis: {
platform: null,
time: null,
capacity1st: "-1",
capacity2nd: "-1"
}
},
name: "Tram 14",
category: "Tram",
number: "14",
operator: "VBZ",
to: "Zürich, Triemli"
},
{
stop: {
station: {
id: "8591341",
name: "Zürich, Schmiede Wiedikon",
score: null,
coordinate: {
type: "WGS84",
x: 8.519122,
y: 47.370446
}
},
arrival: null,
departure: "2012-04-03T00:24:00+02:00",
platform: "",
prognosis: {
platform: null,
time: null,
capacity1st: "-1",
capacity2nd: "-1"
}
},
name: "Tro 33",
category: "Tro",
number: "33",
operator: "VBZ",
to: "Zürich, Albisriederplatz"
},
{
stop: {
station: {
id: "8591341",
name: "Zürich, Schmiede Wiedikon",
score: null,
coordinate: {
type: "WGS84",
x: 8.519122,
y: 47.370446
}
},
arrival: null,
departure: "2012-04-03T00:26:00+02:00",
platform: "",
prognosis: {
platform: null,
time: null,
capacity1st: "-1",
capacity2nd: "-1"
}
},
name: "Tram 9",
category: "Tram",
number: "9",
operator: "VBZ",
to: "Zürich, Langmauerstrasse"
},
{
stop: {
station: {
id: "8591341",
name: "Zürich, Schmiede Wiedikon",
score: null,
coordinate: {
type: "WGS84",
x: 8.519122,
y: 47.370446
}
},
arrival: null,
departure: "2012-04-03T00:29:00+02:00",
platform: "",
prognosis: {
platform: null,
time: null,
capacity1st: "-1",
capacity2nd: "-1"
}
},
name: "Tram 9",
category: "Tram",
number: "9",
operator: "VBZ",
to: "Zürich, Heuried"
},
{
stop: {
station: {
id: "8591341",
name: "Zürich, Schmiede Wiedikon",
score: null,
coordinate: {
type: "WGS84",
x: 8.519122,
y: 47.370446
}
},
arrival: null,
departure: "2012-04-03T00:32:00+02:00",
platform: "",
prognosis: {
platform: null,
time: null,
capacity1st: "-1",
capacity2nd: "-1"
}
},
name: "Bus 67",
category: "Bus",
number: "67",
operator: "VBZ",
to: "Zürich, Dunkelhölzli"
},
{
stop: {
station: {
id: "8591341",
name: "Zürich, Schmiede Wiedikon",
score: null,
coordinate: {
type: "WGS84",
x: 8.519122,
y: 47.370446
}
},
arrival: null,
departure: "2012-04-03T00:34:00+02:00",
platform: "",
prognosis: {
platform: null,
time: null,
capacity1st: "-1",
capacity2nd: "-1"
}
},
name: "Tro 33",
category: "Tro",
number: "33",
operator: "VBZ",
to: "Zürich, Morgental"
},
{
stop: {
station: {
id: "8591341",
name: "Zürich, Schmiede Wiedikon",
score: null,
coordinate: {
type: "WGS84",
x: 8.519122,
y: 47.370446
}
},
arrival: null,
departure: "2012-04-03T00:36:00+02:00",
platform: "",
prognosis: {
platform: null,
time: null,
capacity1st: "-1",
capacity2nd: "-1"
}
},
name: "Tram 14",
category: "Tram",
number: "14",
operator: "VBZ",
to: "Zürich Wiedikon, Bahnhof"
},
{
stop: {
station: {
id: "8591341",
name: "Zürich, Schmiede Wiedikon",
score: null,
coordinate: {
type: "WGS84",
x: 8.519122,
y: 47.370446
}
},
arrival: null,
departure: "2012-04-03T00:38:00+02:00",
platform: "",
prognosis: {
platform: null,
time: null,
capacity1st: "-1",
capacity2nd: "-1"
}
},
name: "Tram 14",
category: "Tram",
number: "14",
operator: "VBZ",
to: "Zürich, Triemli"
},
{
stop: {
station: {
id: "8591341",
name: "Zürich, Schmiede Wiedikon",
score: null,
coordinate: {
type: "WGS84",
x: 8.519122,
y: 47.370446
}
},
arrival: null,
departure: "2012-04-03T00:38:00+02:00",
platform: "",
prognosis: {
platform: null,
time: null,
capacity1st: "-1",
capacity2nd: "-1"
}
},
name: "Tram 9",
category: "Tram",
number: "9",
operator: "VBZ",
to: "Zürich Wiedikon, Bahnhof"
},
{
stop: {
station: {
id: "8591341",
name: "Zürich, Schmiede Wiedikon",
score: null,
coordinate: {
type: "WGS84",
x: 8.519122,
y: 47.370446
}
},
arrival: null,
departure: "2012-04-03T00:39:00+02:00",
platform: "",
prognosis: {
platform: null,
time: null,
capacity1st: "-1",
capacity2nd: "-1"
}
},
name: "Tro 33",
category: "Tro",
number: "33",
operator: "VBZ",
to: "Zürich, Albisriederplatz"
},
{
stop: {
station: {
id: "8591341",
name: "Zürich, Schmiede Wiedikon",
score: null,
coordinate: {
type: "WGS84",
x: 8.519122,
y: 47.370446
}
},
arrival: null,
departure: "2012-04-03T00:44:00+02:00",
platform: "",
prognosis: {
platform: null,
time: null,
capacity1st: "-1",
capacity2nd: "-1"
}
},
name: "Tram 9",
category: "Tram",
number: "9",
operator: "VBZ",
to: "Zürich, Heuried"
},
{
stop: {
station: {
id: "8591341",
name: "Zürich, Schmiede Wiedikon",
score: null,
coordinate: {
type: "WGS84",
x: 8.519122,
y: 47.370446
}
},
arrival: null,
departure: "2012-04-03T00:47:00+02:00",
platform: "",
prognosis: {
platform: null,
time: null,
capacity1st: "-1",
capacity2nd: "-1"
}
},
name: "Bus 67",
category: "Bus",
number: "67",
operator: "VBZ",
to: "Zürich, Dunkelhölzli"
},
{
stop: {
station: {
id: "8591341",
name: "Zürich, Schmiede Wiedikon",
score: null,
coordinate: {
type: "WGS84",
x: 8.519122,
y: 47.370446
}
},
arrival: null,
departure: "2012-04-03T00:51:00+02:00",
platform: "",
prognosis: {
platform: null,
time: null,
capacity1st: "-1",
capacity2nd: "-1"
}
},
name: "Tram 14",
category: "Tram",
number: "14",
operator: "VBZ",
to: "Zürich Wiedikon, Bahnhof"
},
{
stop: {
station: {
id: "8591341",
name: "Zürich, Schmiede Wiedikon",
score: null,
coordinate: {
type: "WGS84",
x: 8.519122,
y: 47.370446
}
},
arrival: null,
departure: "2012-04-03T00:53:00+02:00",
platform: "",
prognosis: {
platform: null,
time: null,
capacity1st: "-1",
capacity2nd: "-1"
}
},
name: "Tram 9",
category: "Tram",
number: "9",
operator: "VBZ",
to: "Zürich Wiedikon, Bahnhof"
},
{
stop: {
station: {
id: "8591341",
name: "Zürich, Schmiede Wiedikon",
score: null,
coordinate: {
type: "WGS84",
x: 8.519122,
y: 47.370446
}
},
arrival: null,
departure: "2012-04-03T00:54:00+02:00",
platform: "",
prognosis: {
platform: null,
time: null,
capacity1st: "-1",
capacity2nd: "-1"
}
},
name: "Tro 33",
category: "Tro",
number: "33",
operator: "VBZ",
to: "Zürich, Albisriederplatz"
}
]
}

it would be cool to have current muster available as public api at http://transport.opendata.ch/head/

if the result is limited using the fields[] parameter, the elements which are not selected for return are returned with value null.
this is due to the fact that the objects with all the public properties get converted to json by json_encode (in Symfony\Component\HttpFoundation\JsonResponse). The way the limitation of the result is implemented, these properties just don't get a value but remain null and therefor get returned.

we should somehow prevent this.

http://localhost/transport/web/api.php/v1/connections?from=bern&to=rüti

"Rüti" probably gets interpreted as "R ti". This is the LocationQuery result:

array(6) {
  [0]=>
  object(Transport\Entity\Location\Station)#96 (4) {
    ["id"]=>
    string(9) "008575426"
    ["name"]=>
    string(18) "Roveredo TI, Miera"
    ["score"]=>
    string(3) "100"
    ["coordinate"]=>
    object(Transport\Entity\Coordinate)#97 (3) {
      ["type"]=>
      string(5) "WGS84"
      ["x"]=>
      float(8.981176)
      ["y"]=>
      float(46.072736)
    }
  }
  [1]=>
  object(Transport\Entity\Location\Station)#98 (4) {
    ["id"]=>
    string(9) "008575427"
    ["name"]=>
    string(18) "Roveredo TI, Paese"
    ["score"]=>
    string(3) "100"
    ["coordinate"]=>
    object(Transport\Entity\Coordinate)#99 (3) {
      ["type"]=>
      string(5) "WGS84"
      ["x"]=>
      float(8.984565)
      ["y"]=>
      float(46.07359)
    }
  }
  [2]=>
  object(Transport\Entity\Location\Station)#100 (4) {
    ["id"]=>
    string(9) "008505207"
    ["name"]=>
    string(8) "Bodio TI"
    ["score"]=>
    string(2) "98"
    ["coordinate"]=>
    object(Transport\Entity\Coordinate)#101 (3) {
      ["type"]=>
      string(5) "WGS84"
      ["x"]=>
      float(8.906557)
      ["y"]=>
      float(46.380248)
    }
  }
  [3]=>
  object(Transport\Entity\Location\Station)#102 (4) {
    ["id"]=>
    string(9) "008575428"
    ["name"]=>
    string(20) "Roveredo TI, Treggia"
    ["score"]=>
    string(2) "98"
    ["coordinate"]=>
    object(Transport\Entity\Coordinate)#103 (3) {
      ["type"]=>
      string(5) "WGS84"
      ["x"]=>
      float(8.990048)
      ["y"]=>
      float(46.075397)
    }
  }
  [4]=>
  object(Transport\Entity\Location\Station)#104 (4) {
    ["id"]=>
    string(9) "008580590"
    ["name"]=>
    string(18) "Bodio TI, Stazione"
    ["score"]=>
    string(2) "92"
    ["coordinate"]=>
    object(Transport\Entity\Coordinate)#105 (3) {
      ["type"]=>
      string(5) "WGS84"
      ["x"]=>
      float(8.906584)
      ["y"]=>
      float(46.380257)
    }
  }
  [5]=>
  object(Transport\Entity\Location\Station)#106 (4) {
    ["id"]=>
    string(9) "008587472"
    ["name"]=>
    string(28) "Bodio TI, Biv. per Personico"
    ["score"]=>
    string(2) "87"
    ["coordinate"]=>
    object(Transport\Entity\Coordinate)#107 (3) {
      ["type"]=>
      string(5) "WGS84"
      ["x"]=>
      float(8.912256)
      ["y"]=>
      float(46.377426)
    }
  }
}

Could someone add a few (bash?)-Scripts to send and receive sample requests/responses from/to HAFAS?

Would be nice for development.

The redis client information aren't configurable. At the moment, the credentials are in the repository and can be access by every body.
Add configuration to silex bootstrap.
This issue is related to #24

Eine Verbindung sollte in mehrere Streckenabschnitte aufgeteilt werden.

Jeden Streckenabschnitt sollte man separat abfragen sollen.

In der Verbindung sollte die Streckenabschnitts-Anzahl (für Umsteigeanzahl) und die verwendeten Transportmittel (zB ['ICE', 'IR', 'Bus']) enthalten sein.

Is there a way to get more connections at the search? On the SBB website there is a way to get the "later connections" if the current connections are too early. Is it possible to implement it into the API or which way do i have to go? Many thanks for your help.

The api returns an empty body and the status code 500 "InternalServerError" for some requests.
One example is:

http://transport.opendata.ch/v1/connections?from=Lausanne&to=Chur

This worked last time i checked on tuesday.

When requesting a stationboard for Zurich Sihlpost it'll also return connections leaving from Zurich Central, because it's seen as the same station.

The list at http://fahrplan.sbb.ch/bin/bhftafel.exe shows what stations are grouped, need to figure out how to include that data and possibly prevent that grouping.

It would be nice to have a parameter that controls the size of the response. E.g.

• 'minimal': for mobile devices
• 'static': ommits prognosis information
• 'normal': is also sent without parameter
• 'extended': includes additional parameters like handicapness and other parameters that are not yet included

Downside:
Other programmers that use no parameter and don't read the doc may not be aware that there is a extened response with parameters they didn't think about..

http://transport.opendata.ch/v1/connections?to=stadelhofen&time=18%3A00&from=z%C3%BCrich%2C+manegg&isArrivalTime=1

-> internal server error

It works when using "zürich stadelhofen" as arrival place.

http://transport.opendata.ch/v1/locations?query=Oberseestrasse%2010,%208640%20Rapperswil returns a station without an ID (obviously, as it doesn't really makes sense to create an ID for every address in Switzerland).

How can I use it in a query like http://transport.opendata.ch/v1/connections?from=Bern&to=Oberseestrasse%2010,%208640%20Rapperswil? It seems to work but just doesn't return any connection.
If I pass something else than an address (e.g. Olten), it works as expected.