search

opentripplanner / OpenTripPlanner

An open source multi-modal trip planner
http://www.opentripplanner.org
Other
2.2k stars 1.03k forks source link

Frequency-based route handling #493

Closed novalis closed 10 years ago

novalis commented 13 years ago

http://groups.google.com/group/gtfs-changes/browse_frm/thread/e6ef325c1ae92b6c

Presently we treat all frequencies.txt files as if exact_times were set. We should fix this.

novalis commented 13 years ago

an example of a trip that uses inexact times

novalis commented 12 years ago

I think we support exact_times (and inexact times)

mattwigway commented 12 years ago

We need to fix the narrative/UI; currently the planner computes a pessimistic time but still presents it as a boarding time. This might lead people to arrive at the stop at that time. Also, it gives the appearance that there is a gap in the itinerary of HEADWAY seconds.

peterxxl commented 11 years ago

Please fix this.

abyrd commented 10 years ago

As OTP evolves, frequency-based trips are generally getting less commit love than scheduled trips. This is simply because many large or prominent GTFS feeds exclusively use timetables and not frequencies. But frequencies are a very important part of many transit systems, including very prominent ones like the Paris metro, which is operated internally using exact times but represented to passengers as a frequency-based service.

Frequency-based service deserves special treatment because the wait and boarding times presented are either worst case or average case estimates rather than exact figures. Properly handling frequency-based trips is the first step toward a more general idea of probabilistic routing that could integrate historical punctuality data.

barbeau commented 10 years ago

Cc'ing @Mona77 on this, since she's just started looking at adding GTFS-rt support for Trip Updates for frequency-based service to OTP (Mona - see above).

@abyrd In your opinion, is this feasible given the current state of frequency-based routing in OTP, or does work need to be done on frequency-based routing first?

bmander commented 10 years ago

screen shot 2014-02-14 at 12 53 57 am

Implemented with b02c290641f34565044016c2411b60f04c442a2a. This adds two fields to the API element: 'headway', and 'isNonExactFrequency'. If 'isNonExactFrequency' is true, then the 'headway' is filled with the seconds between trips. This information is filled by the response builder, and presented the user as "every N mins" for the departure time and "late as h:mm" for the arrival time.

JordenVerwer commented 10 years ago

Hi @bmander,

Thank you for working on this. It's good to see that the holes in OTP's support of different types of transit are being filled.

We've recently begun putting more emphasis on tests in OTP. This was done because many parts of OTP were severely lacking in this area, so whenever you changed anything you'd run the risk of breaking something without knowing it. The old itinerary generator is one such example. I rewrote it in mid-2013 and added an extensive test that covers all fields of the response and most of the edges that can occur in a real graph path. Edges that are still missing are mostly the ones for which I wasn't sure what the correct behavior was (frequency-based trips are an example). I tried not to codify possibly incorrect behavior. The idea is that the test would be expanded as more functionality becomes clearly defined. The current test covers the Dutch use case pretty well (I've heard no complaints), but we're probably going to get some feedback from TriMet and others in the future.

Now that you've added two fields to the response, could you please add these fields to PlanGeneratorTest as well? It would be best if you could, in addition to that, expand the test to cover frequency-based trips as well. Alternatively, you could add another test in that class that covers them. As long as the actual functionality you added gets tested, both approaches will do.

In general, I think it's important that tests are added for any new functionality implemented. If you find that tests are missing for the functionality that's already there, it's okay to complain. It's even better to add a test that covers both the old and the new functionality.

I believe there was much less of a focus on testing when you last worked on OTP, so I can understand why you wouldn't attach too much importance to it at first. Hopefully you'll agree with me that adding tests is important going forward. And of course I'm willing to help if anything is unclear to you.

Regards,

Jorden