Add metadata to public transportation legs.

[ainar]

I already suggested a PR, which is now closed. You can still check my post on the forum.

This one is cleaner and passes all the tests.
Let me know if something is missing.

[ainar]

Let me bump this PR.
It is essential for transit routing to know which type of transport suggests GraphHopper (route_type): bus, tram, subway, etc. The GTFS data always give it, so there is no reason to hide it if only reasons to show it.

Other metadata I added is the line's name (route_long_name and route_short_name) and, if existing, the URL to the public transport service (route_url).

Currently, I use these data for my research.

[5balls]

As a user of graphhopper I find this a very useful feature and would appreciate it, if this would get merged / the functionality be implemented.

[abelcervantes]

I was searching for this feature because this is the main reason why I'm not using graphhopper right now! please merge this!!
Nice job Ainar!

[ainar]

@karussell @michaz @easbar, do you have any opinion on this?

[michaz]

Well. I would say it's not so much hiding the information, as it is not reproducing the full route data.

I mean, if route_short_name and route_long_name and route_type and route_url, why not also route_color and route_text_color and route_desc? Is there some way to decide this in a principled way?

this is the main reason why I'm not using graphhopper right now

@abelcervantes Wait, really, these exact fields not being on the response is the main reason you are not using GraphHopper right now?

[michaz]

Can it be null though?

[ainar]

I mean, if route_short_name and route_long_name and route_type and route_url, why not also route_color and route_text_color and route_desc? Is there some way to decide this in a principled way?

Another way is to add a query parameter similar to the "details" parameter of the classical route.
Then, anyone could choose which attribute to appear in each leg. What do you think about that? I can do it.

[abelcervantes]

Well. I would say it's not so much hiding the information, as it is not reproducing the full route data.

I mean, if route_short_name and route_long_name and route_type and route_url, why not also route_color and route_text_color and route_desc? Is there some way to decide this in a principled way?

this is the main reason why I'm not using graphhopper right now

@abelcervantes Wait, really, these exact fields not being on the response is the main reason you are not using GraphHopper right now?

Yes, basically because it was a mandatory requirement for most of our customers. We had to move to OpenTripPlanner.

[abelcervantes]

Well. I would say it's not so much hiding the information, as it is not reproducing the full route data.

I mean, if route_short_name and route_long_name and route_type and route_url, why not also route_color and route_text_color and route_desc? Is there some way to decide this in a principled way?

this is the main reason why I'm not using graphhopper right now

@abelcervantes Wait, really, these exact fields not being on the response is the main reason you are not using GraphHopper right now?

Agree with @michaz , other fields like route_color and route_text_color among others should be included. In our experience, many customers like to see this kind of information on the UI.