/plan, /trip: API param to not return legGeometry+steps for pre/post transit, transit and direct legs

[traines-source]

Even more important to not waste bandwidth now that soon everything will have shapes.
We have detailedTransfers but that just turns legGeometry off for transfers. Not sure in which case one would like to have legGeometry for transit legs, but not for transfers 🤔
There was some discussion around less heavy plan responses somewhere, haven't found it again. In any case, legGeometry and steps are probably the heaviest parts of responses.

[felixguendling]

There was this Draft mode PR: #1168
But with all the merge conflicts, it's maybe easier to do it again? @e-kotov

[traines-source]

Ah yes, and step instructions should also be removed, they are even bigger.

[e-kotov]

#1168 was very messy and proof of concept. Would be better to do it from scratch.
discussion I stared back then was #1021

[PartTimeDataScientist]

Don't know if that reduces the response significantly but could it be an option to reduce the polyline precision (ore more precisely: make it configurable via an API parameter!). I am aware that the original implementation by Google uses precision 5 but to my limited unterstanding the 5 simply refers to the exponent in the second step and could be anything from 0 to whatever makes sense. At least there is a JS implementation that also has precision 4 in one of the given examples: https://github.com/LiveBy/geojson-polyline?tab=readme-ov-file#usage-1

[traines-source]

I think we intentionally set it to 6 at some point because 5 didn't seem enough for indoor (station) geometries. But yes there was some talk somewhere to be able to set it via an API parameter because not all client implementations support precision 6.