Bus numbering is not consistent

[hb9tst]

In the new beta API, the numbering of buses is not consistent with the old API and is in general not useful. Given this request: http://transport.opendata.ch/v1/connections?from=Renens+Piscine&to=Pully+Gare&time=10:00. Maybe this issue is related to #161.

The old API reports (excerpt of relevant JSON section):

            "name": "BUS 25 55728",
            "category": "BUS",
            "subcategory": null,
            "categoryCode": 6,
            "number": "25",
            "operator": "TL",

And the new one gives:

            "name": "BUS 55739",
            "category": "BUS",
            "subcategory": null,
            "categoryCode": null,
            "number": "25",
            "operator": "TL",

What is useful to know is that the bus line to take is the 25, not the number given to the specific bus on that line (it doesn't help knowing that you have to take the bus with ID 55739...).

The bus number is by the way different in the two outputs because the beta API reports connections that are some time before the requested start (as the actual SBB timetable does, as far as I remember from my experience), whereas the old API doesn't.

[CedricReichenbach]

Looking at the corresponding search.ch API call, the name/number is bad there as well:

"number": "BUS 76669",

However, there are two (sadly undocumented) mysterious properties which contain all the information we need:

"*G": "BUS",
"*L": "25",

In my opinion, it would be great to forward those in the transport API, maybe with more meaningful names though. That would even be an improvement to what was there before, as users could then cleanly extract bus or tram numbers without having to parse name.

[helbling]

please use 'type' and 'line'.
'number' contains some internal id which is only used for very specific technical references.
*G and *L are the original data from HRDF/INFO+. They are usually good as well but type / line have fixes for some cases where *G / *L do not contain what the user expects.