Limit the transit service period

[t2gran]

OTP2 store transit data for each day of service. If there are a service running from 2020-01-01 to 9999-12-31, then OTP2 generates transit data for a lot of days(7979 years), waisting time and memory. Some users of OTP have experienced this problem already.

Allowing the user to limit the period of service days build into the graph would also allow faster load times in a test environment, where 1-3 weeks of data is more than enough for most test-cases.

Expected behavior

OTP should have some threshold that prevent misconfigured transit services to cause OTP to waist memory, build time and load time. By default OTP should limit the service periods to 1 year before the build and until 3 years after. Also, it should be possible to configure this period.

Observed behavior

OTP2 uses a long time to build and load, with near to unlimited transit service periods.

Version of OTP used (exact commit hash or JAR name)

OTP2 with Raptor

Data sets in use (links to GTFS and OSM PBF files)

Set any calendar.txt end_date to a large value.

[t2gran]

This is implemented and merged into dev-2.x.

[marcusyoung]

@t2gran

Please let me know how this limit can be overidden (presumably via build-config.json). I am often using old GTFS files for research purposes, so the arbitary limit of 1 year before is not appropriate.

Thank you.

[t2gran]

@marcusyoung Here sis the doc, let me know if it needs updates/not clear:
https://github.com/opentripplanner/OpenTripPlanner/blob/dev-2.x/docs/Configuration.md#limit-the-transit-service-period

In case someone stumbles on this now, the new link to the build config docs is: https://github.com/opentripplanner/OpenTripPlanner/blob/dev-2.x/docs/BuildConfiguration.md#limit-the-transit-service-period