Is your feature request related to a problem? Please describe.

Currently, when querying trip plans through the GraphQL API, the PointsOnLink type (encoded polyline geometry) provides the encoded points and the number of points, but does not include the calculated distance. This makes it difficult for client applications to determine the distance between individual stops on a leg without manually decoding the polyline and calculating distances themselves.

Goal / high level use-case

A supplier of on-board information screens for new train sets requires the ability to display the distance between consecutive stops on a journey leg. Currently, OTP provides ServiceLink with distance for an entire leg, but this doesn't break down the distance between individual stops. Client applications need this granular distance information to provide accurate real-time information to passengers.

Describe the solution you'd like

Add a distance field to the PointsOnLink GraphQL type that returns the calculated distance in meters for the encoded polyline segment. This would:

• Provide distance in meters as an integer value
• Use spherical distance calculation between coordinates
• Be lazily computed to avoid performance overhead when not requested
• Allow clients to query distance for each segment (e.g., between stops) without needing to decode polylines and calculate distances client-side

The implementation would:

1. Add a distance field to the PointsOnLinkType Transmodel GraphQL schema
2. Extend EncodedPolyline to calculate and cache distance using GeometryUtils.sumDistances()
3. Use the existing SphericalDistanceLibrary for accurate distance calculations

Describe alternatives you've considered

• Compute and keep the distance inside the OTP internal domain model. This would slightly increase memory consumption, but reduce the calculation cost (done once for each intermediate ServiceLink). This solution could copy the distance from the datasource [if availabe] or use the imported data directly resulting in better accuracy/less data loss. This improvement can easily be done later on, in case the suggested solution has any problems with performance or data loss.

  Additional context
  This feature is particularly valuable for:

  • On-board passenger information systems in trains and buses
  • Mobile applications showing distance to next stop
  • Accessibility features providing distance information to visually impaired users
  • Trip planning UIs showing segment-by-segment distance breakdown

The lazy computation approach ensures backward compatibility and minimal performance impact for clients that don't need distance information.