2012.09.13 Weekly Check In

• 13:33 <demory> hello everyone
• 13:33 <novalis_dt> Hi!
• 13:33 -!- grant_ [d819d1d2@gateway/web/freenode/ip.216.25.209.210] has joined #opentripplanner
• 13:33 <demory> let's go ahead with our check in
• 13:33 <novalis_dt> I'm working on adding interlining to RAPTOR and also fixing some bugs in RAPTOR non-transit traversal reported by Skywave.
• 13:34 <demory> my update: still working on new deployer workflow for the North American OTP API -- automated graph build process now includes GTFS merge/transformation step. also busy w/ general Deployer / OTP support
• 13:34 <novalis_dt> Speaking of interlining, grant_, Mike Gilligan claims that the 48 and 88 are interlined but the 48 pulls into one bay and then departs as the 88 from a different bay.
• 13:35 <grant_> hmmm, ok
• 13:36 -!- kpw is now known as kpw_brb
• 13:36 <novalis_dt> I've asked him to help me differentiate
• 13:37 <novalis_dt> Also, a number of people on the gtfs-changes list say that this happens in their area
• 13:37 <grant_> sounds good, I'm curious why trips that do not interline have the same block_id in many cases
• 13:37 -!- eshon [eshon@nat/openplans.org/x-bfadccickjjrmygf] has joined #opentripplanner
• 13:38 <novalis_dt> TriMet's blocks are used for scheduling
• 13:38 <novalis_dt> It all comes out of the same system
• 13:38 <abyrd> I'm doing some profiler runs on AWS. Made a few changes to allow a shared DB server (multiple simultaneous runs). Currently running tests on Matt's merged GTFS.
• 13:39 <abyrd> Experimenting with Analyst runs and data for Seattle and NYC, hopefully we can reuse config for some of these mini-case studies as wiki documentation.
• 13:39 <abyrd> Also cleaning up some loose ends in Timetables.
• 13:41 <FrankP> Grant...you know the block is basically a vehicle. Interlining is when one route transfers to another route on the same vehicle (same block). Now the same physical vehicle might travel on two routes, but it's not interlined if there's a 1/2 hour dead head or layover between that transfer.
• 13:42 <novalis_dt> So the rule is based on length of deadhead/layover?
• 13:43 <FrankP> Not necessarily...
• 13:43 <novalis_dt> What's the actual rule?
• 13:43 <novalis_dt> Mike Gilligan suggests proximity
• 13:43 <novalis_dt> (of the stops)
• 13:45 <FrankP> Sounds good...but proximity of time might be the second part too. If the block sits at that point for more than X minutes, it might be better to tell the customer to transfer vs. interline (pain to get off & back on the bus in certain cases, but...)
• 13:47 <novalis_dt> Hm. I guess we could do that in the plan generator
• 13:47 <FrankP> The loop around PSU comes to mind...those stops are pretty close to each other, but you can't travel around the loop
• 13:47 <mattwigway> also, at least in the south bay, there are routes where the operator leaves the bus and makes everyone get off during an "interline"
• 13:48 <FrankP> yeah, some drivers at TriMet will ask folks to get off the bus if they're on a layover ... don't want to eat lunch or have folks unattended on the bus when they go to the bathroom.
• 13:48 -!- atogle [~[email protected]] has joined #opentripplanner
• 13:49 <novalis_dt> So imagine that we tell people to stay on the bus (because the stops are close together), and the driver makes them get off. In this case, they'll be fine, right?
• 13:49 <novalis_dt> All TriMet stops are wheelchair accessible
• 13:49 <novalis_dt> And there's guaranteed to be enough time for them to get back on the bus and make it to their destination according to the plan
• 13:50 <novalis_dt> (or we don't tell people about the layover at all, in the case of same-route-name interlining)
• 13:50 <mattwigway> novalis_dt, in the PSU loop case that isn't necessarily true.
• 13:50 <novalis_dt> mattwigway, oh?
• 13:50 <mele> right, you have to get off at one stop and go to the other, first one for the opposite direction
• 13:51 <mattwigway> because they make you get off on one side, then the train goes around tot eh other side of the couplet, potentially faster than you can walk.
• 13:52 <novalis_dt> Do those routes actually share a block_id?
• 13:53 <mele> hmm... do you know, grant_ ? I have no idea
• 13:53 <FrankP> The trip around the look goes from MAX Yellow to MAX Green...it's the same block, since it's the same vehicle
• 13:53 <FrankP> Different route, different trip and different stop though
• 13:53 <FrankP> (and not an interline)
• 13:54 -!- eshon [eshon@nat/openplans.org/x-bfadccickjjrmygf] has left #opentripplanner
• 13:55 <novalis_dt> So, you really have to get off, and there's actually the potential to miss the same train?
• 13:56 <novalis_dt> Why do they kick you off at all in that case?
• 13:56 <mele> In theory there's no reason why you would be in that situation, though. You should get off much earlier and walk a block catch a train going back the other way...
• 13:56 <FrankP> I think so (if you're a slow walker, and the security sweep around the loop happens real quick and the train goes fast)...but in the case unlikely. That said, you don't want to tell folks to stay on board.
• 13:56 <mele> They always kick you off at the end of a MAX run just to sweep it for people riding back and forth
• 13:56 <mele> even at the airport
• 13:57 <novalis_dt> OK, well, then we need some way to distinguish.
• 13:57 <mele> wake people up, etc. and the driver takes a break
• 13:57 <novalis_dt> How about we propose a change to GTFS?
• 13:57 <novalis_dt> passenger_interlining_allowed
• 13:57 <novalis_dt> allowed values 0, 1
• 13:58 <novalis_dt> on trips.txt, describing interlining at the end of that trip
• 13:58 <novalis_dt> Would TriMet be able to provide that? For the MAX, the answer would always be no. For other routes, it would apparently depend.
• 13:59 <novalis_dt> I guess for the other cases, the deadhead-distance heuristic would probably mostly be correct.
• 13:59 <FrankP> It's not a bad idea to add a new field ... BTW, I thought we came up with an ad-hoc rule with pickup_type / dropoff_type from stop_times.txt
• 13:59 <FrankP> Specifically for the PSU stuff...
• 14:00 <novalis_dt> FrankP, we did, but it apparently doesn't work
• 14:00 <FrankP> yeah, it did seem limited to end-of-route stuff, etc...
• 14:00 * novalis_dt finds Grant's example
• 14:00 <novalis_dt> http://ride.trimet.org/?submit&fromPlace=4012%20SE%2017TH%20AVE::45.493900,-122.648342&toPlace=OHSU::45.499290,-122.685552&mode=TRANSIT,WALK&min=QUICK&maxWalkDistance=840&time=5:20%20pm&date=9/7/2012#/submit&fromPlace=4012%20SE%2017TH%20AVE::45.493900,-122.648342&toPlace=OHSU::45.499290,-122.685552&mode=TRANSIT,WALK&min=QUICK&maxWalkDistance=840&time=5:20%20pm&date=9/7/2012
• 14:01 <FrankP> BTW, have you guys been in recent contact with Mike G. He's in the best position to talk about this stuff, and discuss a GTFS change, etc...
• 14:01 -!- grant_ [d819d1d2@gateway/web/freenode/ip.216.25.209.210] has quit [Quit: Page closed]
• 14:02 <novalis_dt> I was, a bit, today
• 14:02 -!- grant_h [d819d1d2@gateway/web/freenode/ip.216.25.209.210] has joined #opentripplanner
• 14:02 <novalis_dt> I'll pester him about the PSU loop example.
• 14:03 <grant_h> FYI here's the definition of block_id from the GTFS documentation: The block_id field identifies the block to which the trip belongs. A block consists of two or more sequential trips made using the same vehicle, where a passenger can transfer from one trip to the next just by staying in the vehicle. The block_id must be referenced by two or more trips in trips.txt.
• 14:03 <novalis_dt> Oh.
• 14:03 <novalis_dt> So TriMet is just wrong.
• 14:03 <novalis_dt> But Google gets it right!
• 14:04 <mele> common practice may not fit the strict definition and Google has found a workaround
• 14:04 -!- kpw_brb is now known as kpw
• 14:05 <novalis_dt> Right, which is deeply unpleasant.
• 14:05 <abyrd> Is there any reason not to use the GTFS definition? A passenger information system doesn't ever need to know that two trips are made by the same vehicle unless a passenger can stay on that vehicle.
• 14:05 <novalis_dt> abyrd, because it doesn't match deployed GTFS (specifically TriMet's)
• 14:06 <abyrd> Right, but I'm saying the deployed GTFS could just be changed to match the spec.
• 14:06 <novalis_dt> That would be nice.
• 14:06 <abyrd> Rather than introducing new flags.
• 14:06 <abyrd> If the passenger is forced to get off the vehicle, they different vehicles.
• 14:06 <abyrd> different logical vehicles (I meant to say)
• 14:07 <demory> i imagine a lot of scheduling systems (that export GTFS) consider "blocks" only from the perspective of vehicles, regardless of rider policy
• 14:07 -!- jmaki [jmaki@nat/openplans.org/x-ihlkryksnukfhwrh] has quit [Remote host closed the connection]
• 14:07 <demory> it might be asking a lot for them to always adhere to the gtfs definition
• 14:07 <novalis_dt> demory, yeah, that's certainly true of the MTA's internal systems
• 14:07 -!- jmaki [jmaki@nat/openplans.org/x-leolrlexugtfmhys] has joined #opentripplanner
• 14:08 <demory> so, maybe a new flag is needed -- though i imagine many of those same systems have no idea how to populate them
• 14:08 <mattwigway> my update: just been working on deployment workflow.
• 14:08 <demory> it would have to be a manual / post-export process
• 14:09 <novalis_dt> I guess that avoids destroying data
• 14:09 <abyrd> Sure. I was just thinking that if they even have any 'passengers forced to alight' information coded up, that could be exposed by either generating a new blockID or setting the flag. Neither seems more difficult to implement that the other.
• 14:09 <abyrd> novalis_dt, good point
• 14:11 <grant_h> FrankP: do you know if TriMet has the cases where interlining is allowed explicitly stored anywhere?
• 14:13 <FrankP> not sure...I think it can be derived from the data in some way
• 14:13 <FrankP> (But we have more flags & perms than in the gtfs export)
• 14:14 <novalis_dt> What about just codifying the pickup_type rule?
• 14:14 <FrankP> BTW, the problem with this trip on line 68 up to OHSU seemed to include a dead-head. Anyone ask Mike how that got into the GTFS data? (Which is supposedly devoid of dead-heads)
• 14:15 <novalis_dt> The deadhead is implicit
• 14:15 <novalis_dt> That is, the first trip and second trip share a block
• 14:15 <novalis_dt> So the vehicle must go from the last stop on the first trip to the first stop on the second
• 14:15 <grant_h> yep, the router thinks it's interlining
• 14:21 <grant_h> FrankP: So do you think it's viable to change what we put into block_id to more closely match the documentation (only trips where interlining is allowed would share block_ids)?
• 14:21 <novalis_dt> I just asked Mike Gilligan that
• 14:22 <FrankP> I'd defer to Mike on this and all things GTFS.
• 14:25 <novalis_dt> Cool. Moving on, does anyone have anything else?
• 14:27 <demory> nothing here
• 14:28 <mele> oh i just remembered something
• 14:28 <mele> we were meeting with some folks from salem
• 14:28 <mele> and we were curious about supporting ferries
• 14:28 <mele> whether via osm tagging or some sort of schedule format
• 14:29 <mattwigway> I think that works.
• 14:29 <mele> is that something OTP supports currently?
• 14:29 <demory> i know there are otp deployments w/ ferries now, e.g. the nyc demo
• 14:29 <mele> we'd just need to get a GTFS for the ferries then?
• 14:29 <demory> includes the staten island ferry. i think kpw built the gtfs from scratch
• 14:29 -!- gilligan_trimet [d819d15f@gateway/web/freenode/ip.216.25.209.95] has joined #opentripplanner
• 14:29 <mele> right, we'd (Salem-Keizer transit) need to do that too
• 14:30 <mattwigway> http://sfbay.deployer.opentripplanner.org/#/submit&fromPlace=37.777736,-122.425096&toPlace=38.102650,-122.241075&mode=TRANSIT,WALK&min=QUICK&maxWalkDistance=840&time=11:29%20am&date=9/13/2012&arr=Depart&itinID=1&wheelchair=false
• 14:30 <novalis_dt> gilligan_trimet, hi!
• 14:30 <mele> ok
• 14:30 <mele> thanks
• 14:30 <mattwigway> That has a ferry.
• 14:30 <mele> mattwigway haha I love the icon
• 14:30 <gilligan_trimet> the PSU look example that was brought up has the correct pickup_type so the proximitiy logic should work
• 14:32 <gilligan_trimet> also, another possible solution is assigning the stops at a transit center to a parent station, and never allow interlining unless trips have the same end/start stops or stations
• 14:32 <novalis_dt> gilligan_trimet, I don't want to implement proximity generally, since mattwigway has pointed out cases where that fails (outside of TriMet)
• 14:32 <gilligan_trimet> dt, how about the parent station idea?
• 14:32 <novalis_dt> I'm not sure about that
• 14:33 <novalis_dt> I guess I could check to see how it would work in Seattle
• 14:33 <novalis_dt> But I don't have access to Wojciech's feeds
• 14:35 <mattwigway> novalis_dt, what if we did this like custom namers.
• 14:35 <novalis_dt> I would strongly prefer to avoid more configuration
• 14:35 <mattwigway> Had a class, Spring configured, that decides whether an interline is allowable or not.
• 14:35 <mattwigway> If not, no PatternInterlineDwell edge is created.
• 14:35 <mattwigway> +1 on that.
• 14:35 <mattwigway> (less configuration)
• 14:36 <novalis_dt> in KCmetro, there are cases of interlining between stops that do not share a parent station
• 14:36 <novalis_dt> I feel that the pickup_type rule is probably the strongest of the available options
• 14:37 <novalis_dt> Because it requires no changes to the GTFS spec, it makes logical sense, and it allows non-conforming block IDs to be kept (since they are still useful for tracking/prediction)
• 14:37 <novalis_dt> The question is: how hard would it be to implement for cases like grant's trip?
• 14:40 <gilligan_trimet> novalis_dt, it would be difficult for us because the stop is shared by many routes and pickups are allowed on the others
• 14:41 <novalis_dt> Isn't pickup_type a feature of stop_times, not stops?
• 14:41 <gilligan_trimet> yes, but in our database, it is a feature of the stop
• 14:42 <novalis_dt> Did you write the GTFS generation script (or can you modify it)?
• 14:42 <novalis_dt> Because if you wanted to use the parent station or proximity heuristics internally, to generate those pickup_types, that would work fine.
• 14:43 <gilligan_trimet> I think that is doable, just depends on how high of a priority management puts on this fix :)
• 14:45 <novalis_dt> OK, then I'm going to mark the bug closed, and leave it to you guys?
• 14:49 <FrankP> novalis_dt, were there any code changes made (non RAPTOR) in regards to this? (e.g., we're running code from stable, that's about a month old)
• 14:49 <novalis_dt> FrankP, not that I can think of