Split routeShortName into separate attributes, pass through more attributes like route_type

[GerdC]

(I hope I'm correct here an this is not (purely) a transitous property.)

It appears that the Motis 2 plan response is (with some deviations) modeled after the old OTP REST plan response.

With OTP, the route name that is displayed is typically returned in the property leg.routeshortname.

in OTP, Urban modes this routeshortname typically consists if typically 1-3 characters without a mode name (like S1 or U5 or 44).
For trains, typically an abbreviation of the train type is added (like IC 217)

(for more talkative names, OTP returns routelongname)

In this routing example from Amsterdam Airport to Rijksmuseum,

Metro 52 routehortname appears to contain something like a trip id. This makes not much sense.

That the short name contains mode descriptions like "Bus" and "Tram" is very unusual and debatable, especially since there is a separate property for mode.

For "Intercity 3555" I would expect "IC 3555" in routeshortname.

Maybe there is a better way what to map into routeshortname?

There is always the possibility to fill leg.routelongname, if somebody wants it.

[felixguendling]

The basic problem is that GTFS datasets are very inconsistent with the use of

• route name short
• route name long
• trip name short

The GTFS standard also doesn't contain a property specifically meant to be displayed to the customer. I think something like "trip display name" would be useful. This is what we tried to do with the leg.routeShortName - something you can directly display to the user. However, to make this actually work, we would need dataset specific rules on how to build this string.

For example in Germany, long distance trains and S-Bahn both have train numbers (which are often contained in the trip short name) but for the S-Bahn the user would expect the line information (often modeled as route name short) like S1, S2, etc. (not S 12345) but for long distance trains usually the line (which also exists!) is not used but the train number is used instead. Additionally, some datasets would put "S3" into route short name, others only "3" and would expect you to derive the "S" from the route type.

Long story short: solving this problem (to generate a human readable display name for each trip) would require custom logic per dataset. This logic could either be implemented client side (in this case MOTIS would've to provide all fields separately which it does not at the moment) or server side (which would require a script running together with the import).

KDE Itinerary for example enriches timetable data with line colors, provider images, etc. from Wiki Data to generate a proper display of trip information for the user. I would consider this a bit out of scope for MOTIS for now.

[laem]

in this case MOTIS would've to provide all fields separately which it does not at the moment

This would be very usefull to me.

See the difference between the GTFS attributes (capture 1) and Motis's attributes (capture 2).

The long name is quite important. The clasz attribute is hard to handle in UIs that are based on GTFS's route_type schema, there is a loss of information. Motis' "name" attribute includes the prefix "bus" which is not useful here, as the UI itself will handle the display of the information that this move is a bus using the route_type attribute (with an icon, a color, a custom i18n text, etc.).

In cartes.app, despite the inclusion of route_color and route_text_color in the response, I still need to call my node-GTFS API for each move to get these informations, which makes the display of the results slower (or clunkier with a late update).

[felixguendling]

I agree, having those attributes separately would be nice.
I currently don't have capacity to implement it.
I added it to #452 for now.