Removal of support for MODIFIED ScheduleRelationship in GTFS realtime updates

[lapp...@gmail.com]

We are considering to remove support for MODIFIED ScheduleRelationship in OpenTripPlanner 2. This type was a proposal but it was never officially merged in to the GTFS realtime specification.

If anyone is still using it and really needs it, let us know. GTFS realtime supports other ways to achieve what could be done through the MODIFIED ScheduleRelationship.

Relevant github issue.

[Stefan de Konink]

How would OTP2 wants to receive a modified trip? For example a detour of a
train.

--
Stefan

[lapp...@gmail.com]

For smaller changes we could use https://github.com/google/transit/pull/219 but the support hasn't yet been implemented in OTP. For larger changes maybe https://docs.google.com/document/d/1oPfQ6Xvui0g3xiy1pNiyu5cWFLhvrTVyvYsMVKGyGWM/edit#heading=h.mm6bblup6h8d could in theory be implemented. However, if no one is currently using the MODIFIED ScheduleRelationship, we could remove support for it now and then later implement support for some other way to model these stop changes or detours when there is need for it from some project.

[Stefan de Konink]

On Tuesday, February 15, 2022 1:21:26 PM CET, lapp...@gmail.com wrote:
> For smaller changes we could use https://github.com/google/transit/pull/219
> but the support hasn't yet been implemented in OTP. For larger changes
> maybe
> https://docs.google.com/document/d/1oPfQ6Xvui0g3xiy1pNiyu5cWFLhvrTVyvYsMVKGyGWM/edit#heading=h.mm6bblup6h8d
>
> could in theory be implemented. However, if no one is currently using the
> MODIFIED ScheduleRelationship, we could remove support for it now and then
> later implement support for some other way to model these stop changes or
> detours when there is need for it from some project.

ServiceChanges is overly complex. In my perspective if GTFS-RT matches the
SIRI-PT/ET structure it is trivial to do a detour (if the journey planner
would allow it). Sure people can argue: Then we cannot have "pretty
shapes". Shapes aren't pretty, and map matching becomes a requirement
anyway. Then we cannot have new stops. Ticketing systems cannot introduces
new stops on the fly either, so having a stable network in GTFS is the
basis of doing detours right. If the situation is so bad that everything
falls apart and the data is available to fix it: just introduce a new
timetable.

I don't see why removing functionality would have priority over first
implementing the alternative.

--
Stefan

[Leonard Ehrenfried]

> I don't see why removing functionality would have priority over first
> implementing the alternative.

Because every feature has maintenance costs, particularly when refactoring. There has been a push lately to remove features (cruft?) that complicate the code and appear unused.

If you work for an organisation that uses this feature in OTP2 we would love it if you join the developer meetings that happen twice a week: https://github.com/opentripplanner/OpenTripPlanner/blob/dev-2.x/CONTRIBUTING.md#primary-channels-of-communication

There we can discuss how to accommodate your use cases.

All the best.

--
Leonard Ehrenfried

> --
> Stefan
>
> --
> You received this message because you are subscribed to the Google
> Groups "OpenTripPlanner Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to opentripplanner...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/opentripplanner-dev/f9b799ab-5e54-4301-a6a2-192f7b44d2d5%40konink.de.

[Stefan de Konink]

On Tuesday, February 15, 2022 4:16:25 PM CET, Leonard Ehrenfried wrote:
> If you work for an organisation that uses this feature in OTP2
> we would love it if you join the developer meetings that happen
> twice a week:
> https://github.com/opentripplanner/OpenTripPlanner/blob/dev-2.x/CONTRIBUTING.md#primary-channels-of-communication

We deliver this data (and software) to such organisations. I think The
Netherlands is represented there. But I'll ask around if someone can put it
on the table there.

--
Stefan