Weekly check in 2012.09.13 - GeoSmartCity-CIP/gsc-opentripplanner GitHub Wiki
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: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: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 <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