Support new API call of 2nd class wifi

[Nakaner]

The wifi for 2nd class passengers on ICE trains (where the free 2nd class wifi is enabled) offers an additional API call:

$ curl "https://www.ombord.info/api/jsonp/position/"
({
    "version":"1.7",
    "time":"1476205886",
    "age":"0",
    "latitude":"52.444865",
    "longitude":"10.29791",
    "altitude":"56.3",
    "speed":"53.662",
    "cmg":"252.94",
    "satellites":"10",
    "mode":"3"
});

In difference to the status call of ICE Portal API, this call also returns the number of satellites and some more fields whose meaning needs to be investigated.

source

[DerDakon]

ICE 888 has the new Wifi, but that URL just gives 403.

[madonius]

In the ICE787, the call works excactly as posted. Maybe there should be a check-call implemented to figure out with which API we are dealing with.

[rurseekatze]

The version of the API depends on the vehicle, so the train trip ids (ICE 888 and ICE 787) are not relevant here.

[madonius]

You are right, for me it was the ICE4

[rurseekatze]

ICE 888 has the new Wifi, but that URL just gives 403.

Same problem in my tests.

[Nakaner]

ICE 5 returns:

({
    "version":"1.9",
    "time":"1487661628",
    "age":"1",
    "latitude":"48.675208",
    "longitude":"8.10848",
    "altitude":"136.7",
    "speed":"69.331",
    "cmg":"0.0",
    "satellites":"10",
    "mode":"3"
});

The speed is obvious wrong because I am pretty sure that the train is currently faster than 160 kph (here between Baden-Baden and Offenburg on the high speed tracks).

[Nakaner]

That's the output on ICE 72 (today Tz 188) between Friesenheim (Baden) and Offenburg (speed ~ 155 kph):

({
    "version":"1.9",
    "time":"1487683096",
    "age":"1",
    "latitude":"48.453297",
    "longitude":"7.912263",
    "altitude":"157.4",
    "speed":"43.52",
    "cmg":"0.0",
    "satellites":"8",
    "mode":"3"
});

and a few kilometres north in the sharp (80 kph) curve of Offenburg:

({
    "version":"1.9",
    "time":"1487683220",
    "age":"0",
    "latitude":"48.466857",
    "longitude":"7.949183",
    "altitude":"164.2",
    "speed":"21.534",
    "cmg":"0.0",
    "satellites":"7",
    "mode":"3"
});

It looks that you have to multiply the speed returned by the API version 1.9 by a value between 3.4 and 3.8.

I did some GPS logging using a separated device in my compartment and will compare the API with my own measurements.

EDIT: It looks that the speed being returned is in m/s.

[madonius]

I can second that. The speed is in metres/second.

[Nakaner]

I think that this issue can be closed because the new ICE Portal is being/was deployed on all trains which will get it and logger.sh has been supporting it since last weekend.

[rurseekatze]

Is https://www.ombord.info/ no longer in use or is it an alternative URL that returns more or less the same data like https://portal.imice.de/?

[Nakaner]

@rurseekatze wrote:

Is https://www.ombord.info/ no longer in use or is it an alternative URL that returns more or less the same data like https://portal.imice.de/?

I have not tested whether omboard.info is still usable if portal.imice.de is available. But @DerDakon wrote to me on IRC yesterday that there are still ICEs without portal.imice.de which have omboard.info.

[DerDakon]

The coaches had Wifi-im-ICE, but portal.imice.de was not reachable. This was e.g. in coach 802626 today (ICE 76).

[Nakaner]

On an ICE (BR 406) with portal.imice.de, `curl "https://www.ombord.info/api/jsonp/position/" returns

({
    "version":"1.9",
    "time":"1495394121",
    "age":"1",
    "latitude":"50.986033",
    "longitude":"7.018155",
    "altitude":"49.7",
    "speed":"21.698",
    "cmg":"0.0",
    "satellites":"9",
    "mode":"3"
});

We shold keep this issue open until the script supports both and automatically selects the better one.

We could test which API responds faster and is more reliable in terms of availability. You sometimes get timeouts with the ICE portal.