Weekly check in 2012.07.05

• <abyrd> Hey everyone, should we get started with the weekly check-in?
• <novalis_dt> Sure!
• <kpw> let's do a quick go-round:
• <kpw> demory is on vacation
• <kpw> mattwigway (matt conway)
• <mattwigway> hi
• <kpw> joined us this week as an intern
• <kpw> demory and mattwigway have been working together this week to map out gtfs coverage for north america
• <novalis_dt> I've checked in some new APIs for first/last trip of the day, as well as some tests for most or all of our APIs. This uncovered some bugs, which I fixed. I've also made default routing parameters configurable via XML, so that things like a default maxTransfers can be set without messing with the front-end.
• <mele> about time :)
• <kpw> novalis_dt, responding to your email on about this now
• <novalis_dt> kpw, awesome
• <kpw> can you and abyrd sync up about the transfer time question?
• <novalis_dt> kpw, sure, but really it's a question for TriMet
• <kpw> ah, yes, but you had a question about symetry in arrvial departure slack times
• <kpw> anyway, email inbond
• <novalis_dt> Cool.
• <kpw> what else?
• <abyrd> I just patched up MOA*, and am building a NYC graph so I can generate some random trips and take a look at where we're getting poor performance.
• <abyrd> Then I'm going to take a look at the distribution of route/hop speeds and spacing to see if we can see some kind of natural hierarchy.
• <mele> FYI I heard a NYC OSM group is starting to get together to get the data in better shape there
• <mele> http://www.meetup.com/osm-nyc
• <novalis_dt> The issue, for the record, is that TriMet wants people to arrive 5 minutes early for their transit; this implies that the transfer time should be ten minutes (since if one bus can be five minutes early then another can be five minutes late). That seems extremely long. If we treat initial boarding and transfer differently, we're going to run into weird problems when reverse-optimizing paths.
• • FrankP_ (1815504e@gateway/web/freenode/ip.24.21.80.78) has joined #opentripplanner
• <mele> If I remember correctly from our discussion about that here, I think we just wanted 5 minutes for all cases, right FrankP_ ?
• <abyrd> there are work-arounds if we want initial and final slack time to be equal to transfer slack
• <novalis_dt> Well, actually, I wanted to offer another option
• <abyrd> it was one of the options we considered at the time that decision was originally made
• <novalis_dt> Which was to have min_transfer_time in transfers.txt override the default
• <novalis_dt> That is, act as a ceiling rather than a floor
• <novalis_dt> Or, not a ceiling, but an alternate floor
• <novalis_dt> abyrd, but remind me how initial/final=transfer would work?
• <abyrd> we'd have to add a dummy edge to the end of the path before reversing
• • kpw is now known as kpw_brb
• <FrankP_> mele, yes, 5 minutes at beginning of the leg. novalis_dt, only concern with mucking with transfers.txt is how google would handle that.
• <novalis_dt> Well, that's unpleasant, but I guess possible
• <abyrd> since we know when we're at the first boarding, but not when we're at the last alighting
• <novalis_dt> FrankP, ok, fair enough
• <abyrd> yeah, it's just kind of ugly, but I believe we rejected that option on those grounds only, and the reasoning that it made more sense for transfer slack to equal 2x initial boarding slack
• <novalis_dt> FrankP, so is 5 minutes also OK for transfer slack?
• <FrankP_> I think it's a good value...I'll double check with Jeff as to what we currently do. Would be best to have two parameters to control board and transfer, I think...
• <FrankP_> (Controlled via graph-builder.xml and/or context.xml
• <novalis_dt> FrankP, all planning parameters are now controllable via application-context.xml
• <mattwigway> abyrd, if you're doing an arrive-by search, do you still know the first boarding?
• <novalis_dt> That's the problem with having two parameters
• <novalis_dt> That is, during the search, we don't know whether something is a final alighting or an intermediate alighting
• <abyrd> mattwigway, no, you don't
• <abyrd> but I suppose we could just postprocess the itineraries to add in slack according to some rules
• <novalis_dt> abyrd, yes, that would be possible. Let me just do that.
• • novalis_dt tickets
• <novalis_dt> FrankP, do you also want the 5 minutes on alight?
• <novalis_dt> There are two scenarios for this
• <novalis_dt> First: Someone plans a trip to depart at 5:00. We make a plan, telling them to get to the bus stop at 5:30 for a 5:35 bus. Their bus arrives at 6:30, but (and here's the parameter question) we tell them it arrives at 6:35 (or whatever that parameter says).
• <novalis_dt> Second: someone wants to arrive at their destination at 6:30. We have to tell them a bus earlier than the 5:35 bus (which arrives at 6:30 exactly), to give them the 5 minutes of slack on the back end
• <FrankP_> In both cases, I'm not sure why you'd buffer the arrival with slack time.
• <novalis_dt> Because we want to give people plans that are safe.
• <FrankP_> The slack time is only used to get the customer to a bus early before it departs. Not sure why ever apply it to an arrival that's not a transfer
• <abyrd> because to the user, the final vehicle arrival time serves the same purpose (on an arrive-by search) as the first vehicle departure time (for a depart-after search)
• <abyrd> it most directly influences the reliability of the itinerary for their stated goal
• <abyrd> but if you seriously don't want slack in both directions, this becomes less difficult
• <FrankP_> I'm just not sure why there'd ever be slack at the end of a trip...the two scenarios Dave painted...you want to tell the customer to get to the stop at 5:30 for the 5:35 departure.
• <novalis_dt> I would want slack because TriMet buses are allowed to be N minutes late.
• <FrankP_> I don't know about that. The bus is late, then it's late at the arrival. The 5 minute slack is more to get the customer on the bus...the times we show are often interpolated, and the bus operator is only measured at getting to a timepoint at a certain point. The driver can floor it between interpolated stops, blowing by those times, and still be ''on time"
• <novalis_dt> That is, I want to give people a route that is "guaranteed" (according to TriMet's allowable lateness) to get to their destination by time T, rather than one which is merely scheduled to arrive then
• <novalis_dt> Wait, you're saying that TriMet doesn't have allowable lateness?
• <mele> things are often later than that around here, novalis_dt --- i think i'd rather have OTP tell me when the bus is scheduled and not exclude it from a possible plan-- letting me decide whether that's early enough for me
• <FrankP_> No...when you arrive at a timepoint late, your late (as an operator).
• <FrankP_> The 5 minute rule is a marketing thing, so people don't get passed up.
• <FrankP_> The stops in between timepoints are not guarenteed times from a TriMet operational standpoint.
• <novalis_dt> And are non-timepoints ever used for transfers?
• <novalis_dt> Incidentally, we could hteoretically support a timepoint/non-timepoint distinction if the GTFS did not contain interpolated times
• <novalis_dt> We don't know, tho
• <novalis_dt> er, we don't now
• <novalis_dt> But anyway, if we're going to postprocess itineraries, then I think we can just apply transfer slack at transfers (that is, on 2nd and subsequent boardings), and then postprocess to apply configurable arrival/departure slack.
• <FrankP_> Good question...I'm sure there are some preferred transfers that are not timepoints. (I'll double check). That said, the 5 minute slack at transfers serves the same intended purpose.
• • grant_h (43a8cde1@gateway/web/freenode/ip.67.168.205.225) has joined #opentripplanner
• <FrankP_> BTW, there are some timepoints that are not stops, and in one case, the bus didn't stop at that timepoint.
• <abyrd> so this is all less about accounting for actual variability in schedules, and more about influencing customers to leave a little early, so it is asymmetric? it applies specifically to the forward direction.
• <FrankP_> Timepoints are spread out at (a desirable) 10 minute interval to control the pace of the vehicle.
• <novalis_dt> abyrd, well, it applies to both search directions -- just it only applies to first (temporal) boardings
• <FrankP_> abyrd, yes...
• <abyrd> right... meaning the forward direction from the user's perception, where time runs forward
• <novalis_dt> Right.
• <abyrd> novalis_dt, while postprocessing is a decent option, it will mean rewriting a bunch of time fields etc. does it solve a problem that can't be solved by inserting slack as we do now?
• <abyrd> it seems that with the requirement that transfer slack >= board slack + alight slack all works fine
• <novalis_dt> Right, I guess transfer slack can be larger just not smaler
• <novalis_dt> Except
• <abyrd> it couldn't be smaller, but I can't think of any reason it should be
• <novalis_dt> OK, right, that should work
• <abyrd> and of course the alight slack would have to be the same amount of time, no matter which direction the alight edge was being traversed
• • gboudreau (~gboudreau@mail2.danslereseau.com) has left #opentripplanner ("Textual IRC Client: http://www.textualapp.com/")
• <novalis_dt> Yes. And then transfers would make up the distance
• <novalis_dt> er difference
• <abyrd> of course usually alight=board and transfer = alight+board, and there's a range check if someone specifies a transfer time
• <FrankP_> so to sum up, what parameters do I have? an alight_slack and board_slack? And I could set alight_slack=0 minutes, and board_slack=5 minutes...then I'd see the 5 minute rule on the first board, and at each transfer...yeah?
• <novalis_dt> Actually, three parameters; there will also be a transfer_slack which you will set to 5 minutes.
• <novalis_dt> Hopefully, this will be the last refactor of this :)
• <FrankP_> okay, so transfer_slack is independent of alight & board...that works, and seems really flexible (esp. if I'm missing something here at TriMet, and we care about the alight slack time).
• <novalis_dt> Well, not truly independent
• <novalis_dt> But independent so long as it is >= board slack + alight slack
• <FrankP_> okay, that sounds good...so if someone sets board+alight=5 and transfer=3, what happens? transfer gets set to 5?
• <novalis_dt> We'll give an error message, I think
• <novalis_dt> That seems better than giving people unexpected results and having them try to piece together what has gone wrong
• <FrankP_> One last clarifying question: I set board=3, alight=0 and transfer=5 ... everything works, and I'll only see a 5 minute slack time on a transfer?
• <novalis_dt> Yes.
• <FrankP_> yeah, that should work fine.
• <abyrd> and FrankP_, if you set alight_slack=0 minutes, and board_slack=5 minutes, but do not set transfer slack, it should naturally be 5+0=5 minutes
• <FrankP_> abyrd...yes, that would make sense to me...mele?
• <mele> yeah, sounds good. just try to make it clear in the config doc instructions cause it does seem like it might be a little confusing for a new user
• <novalis_dt> Yeah, the default config will be sensible anyway
• <FrankP_> we'll just point them at this conversation :-)
• <novalis_dt> Now, having bored everyone to death with our slacking, does anyone have anything else?
• <FrankP_> Have there been any fixes in OTP in the last month that should be put into our production OTP instance?
• <FrankP_> Things seem to be running fine with June 6th code, and I'm going to keep that running for awhile.
• • novalis_dt reads some logs
• <novalis_dt> We do have first/last trip APIs now, if you wanted to add that functionality to the front-end.
• <novalis_dt> Oh, zag removal
• <novalis_dt> That's a big one
• <FrankP_> Really...hmm
• <mele> yeah i'd really like to see that
• <FrankP_> (first/last)
• <novalis_dt> Just do /ws/plan/first instead of /ws/plan
• <FrankP_> BTW, zag? is that islands?
• <mele> to make the itinerarly less annoying at street crossings where there are crosswalks & sidewalks in OSM
• <novalis_dt> https://github.com/openplans/OpenTripPlanner/issues/767 <-- description of issue
• <FrankP_> abryd, you recommened to nirmal this mornign to use PruneFloatingIslands is that something we all should be doing?
• <abyrd> not necessarily, it depends on data quality
• <FrankP_> okay, won't add it to our stuff then..thanks
• <abyrd> since you have an OSM maintenance process, it would be a good idea to keep an eye out for disconnected areas. then you won't need to remove them.
• <abyrd> I just happen to know that in san francisco OSM there are a lot of disconnected station platforms
• <abyrd> and so on
• <FrankP_> yeah, we have ~5 disconnected stops ... most due to street construction
• <novalis_dt> Meaning that they should be disconnected?
• <mele> yeah, they're not actually open
• <mele> unless there are some I need to fix Frank?
• <abyrd> I'm referring to disconnected as in the OSM ways don't share nodes, so you can't route from one way to another