Add a link to the trip destination on journey's display_information

[pbougue]

This would help Transportr solve: https://github.com/grote/Transportr/issues/274#issuecomment-271101389 And the navitia's googlegroup topic is here: https://groups.google.com/forum/#!topic/navitia/7TZQcxnaU2Q

The idea is: the route is not enough to match the destination of the vj in a lot of cases (depending on the data), and the display_information only gives the label of the last stop. Most of it is C++ work in pb_converter. Adding an uri of this stop or a link (and the corresponding details in response) seems to be the good/easiest work to do. A display_information.direction_uri might be a solution too.

[grote]

Thanks for creating this ticket!

If at all possible, I would like to avoid having to do a second HTTP request to get the stop_area of the route direction and have this information included in the response to the departures query.

[pbougue]

You're welcome :) And what more information do you need? Uri, name, label...?

[grote]

Ideally, the API returns a full stop_area object for the line's direction.

It does that already, only that the stop_area is wrong if the line does not have the direction_id set, so this ticket could also be a bug and not an enhancement. Check out this screenshot from the playground from grote/Transportr#274:

The route has a direction which has a stop_area only that it is the wrong one (from the line's other direction).

[pbougue]

As @stifoon said, we rely on data for route and direction and we don't build one for each stop_area that is the end of a vehicle_journey (and even doing that would not be enough some times). So you can't safely process route's direction to know which way the vehicle is heading (and it's even more the case in GTFS format, as you only have 2 directions). In the case you're providing, only one route is given in data, so we return always that same unique one.

So putting the complete final stop_area in display_information (probably in links part to mutualize) would do the job for you?

[grote]

So putting the complete final stop_area in display_information (probably in links part to mutualize) would do the job for you?

I don't know what you mean by "in links part to mutualize", but otherwise, yes.

[pbougue]

The idea would be to add in display_information.links something like:

            {
                "id": "stop_area:bobito",
                "internal": true,
                "rel": "destination",
                "templated": false,
                "type": "stop_area",
            }

And at the root of the response a stop_areas table containing that "bobito" stop_area (so if we have 2 departures with the same destination, the stop_area informations are mutualized)

[ialokim]

Any news on this issue?

[pbougue]

I'm not in the team working on Navitia anymore, but as far as I know, no work is planned for that. Any contribution is welcome though (as it's not so complicated work, support would be provided quickly I guess).