Route color

[laem]

In the demo app, the color of routes depends on the route type (train, bus, fast train, etc.).

However, route_color is a standard attribute in GTFS timetables, that is essential to build UIs.

Is there a way to pull this kind of attribute from the intermodal API request ?

Alternatively, a route to expose the attributes of a GTFS route ? Or should we handle this kind of request using another GTFS parser API ?

[felixguendling]

At the moment, this is not implemented. The attribute is ignored while parsing and doesn't get stored anywhere. So currently, it cannot be exposed via the API. It's kind of a TODO without concrete schedule when it will be done. I guess it's not a big deal to implemented it but until now everyone was fine with the category based colouring.

[laem]

Thanks. I've implemented a small node server to pull these informations form the GTFS zip files. The server can be run easily on a PaaS platform (like scalingo). It requires followup requests after the Motis intermodal computation, but in practice that's fine, considering the speed of this node server.

This route precisely https://github.com/laem/gtfs/blob/master/server.js#L76.

Could be helpful for people with the same needs as mine, until it is implemented in Motis :)

[felixguendling]

Thank you for providing your solution! 👍

[laem]

Well, after some tests : Motis parses 100 % of my ~7 GTFS files, while node-GTFS fails for 4 of them for various reasons. I might look into it.

Edit : Erratum, with the ignoreDuplicates option set to true, all pass !

[felixguendling]

MOTIS is not a validator. Our concept is "garbage in - garbage out". There are enough GTFS validation tools (and tools like gtfs-tidy) out there that everyone can use to check for validity. MOTIS expects valid data but will not complain if it contains errors. Instead, MOTIS fixes everything that's required to have a valid routing graph. But for a production system, I would recommend to use a validator before passing data to MOTIS.

[laem]

Hi, after some looking around, I've found the... lookup module through the Wiki.

It doesn't look well documented. I guess for now, the only documentation si the source code ? https://github.com/motis-project/motis/tree/master/modules/lookup/src

Which is quite fine, actually. Tests are also helpful. Asking just in case.

I'm trying to evaluate how easily I could drop my node-GTFS dependency and go full motis.

A colleague just made a pull request to node-GTFS adding lookup of stations by lat, lon. BlinkTagInc/node-gtfs#152

It looks like Motis already has that with lookup/geo_station.

[felixguendling]

Yes, the geo station lookup is implemented (now in the nigiri module, lookup depends on the old core).

It's not really a documentation, but the *Request and *Response types are self-explanatory in most cases:
https://github.com/motis-project/motis/tree/master/protocol/lookup

Currently, only LookupGeoStationRequest is implemented in nigiri but most other lookup requests would also be easy to implement using the nigiri data structures.

To have a more complete coverage of GTFS in the MOTIS API, attributes like route_id, route_color, shapes, etc. would need to be implemented in nigiri which is possbile but a bit more work.

[felixguendling]

I'm trying to evaluate how easily I could drop my node-GTFS dependency and go full motis.

Which APIs are missing?

[laem]

To have a more complete coverage of GTFS in the MOTIS API, attributes like route_id, route_color, shapes, etc. would need to be implemented in nigiri which is possbile but a bit more work.

Well for now, mostly this I guess. I've found node-GTFS since I mostly write JS code, and their documentation is quite good. I need to try a rewrite.

[laem]

Implemented in
motis-project/nigiri#67