Weekly check in 2012.12.06 - GeoSmartCity-CIP/gsc-opentripplanner GitHub Wiki
13:32 <demory> hi everyone
13:32 <demory> should we get started?
13:34 <demory> my update -- been making good progress on the calltaker interface. traveling for the weekend starting tomorrow but I plan to have a preliminary demo online for you all to see at Trimet before I leave
13:35 <demory> ^ FrankP FrankX mele grant_h
13:35 <novalis_dt> I fixed up a bug in arrive-by searches in RAPTOR
13:35 <novalis_dt> I'm going to look at linking a bit more
13:36 <novalis_dt> Avi made some changes to the linking code which hopefully clean things up without affecting behavior
13:36 <novalis_dt> Well, also he broke the build on master in Eclipse
13:36 <novalis_dt> But he'll probably fix that up
13:37 <FrankX> Cool David & Dave ... looking forward to seeing both new code and new release when ready (again, we could wait a month if that means 2.0)
13:37 <abyrd> I'm still experimenting with long-distance searches. There's a reasonably fast setup running on opentripplanner.nl
13:38 <novalis_dt> i.e. with direct stop-to-stop linking?
13:40 <FrankX> My update: since last meeting, we've been building and testing the OTP code in head against trimet data ... Grant's been in touch with Dave on a category of issues around Max stops.
13:40 <abyrd> for example here's a brussels to berlin trip
13:41 <abyrd> novalis_dt, yes with really dumb direct stop linking and on-street searches at the ends
13:41 <abyrd> fortunately thomas is adding the official transfer data to the GTFS feeds so we can do proper transfers
13:41 <abyrd> or at least the same transfers that would be found by the existing national trip planner
13:43 <abyrd> novalis_dt, I'd like to talk to you some time about comparing this with RAPTOR
13:43 <abyrd> but I should read more of the code first
13:44 <abyrd> Note that this is using the new open data for Berlin (hurray)
13:47 <novalis_dt> Yeah, it's going to be faster, since our RAPTOR uses dijkstra for on-street
13:49 <novalis_dt> Anyway, I assume you've tested against raptor?
13:49 <abyrd> right but I'd like to try raptor as originally intended with no on-street
13:50 <novalis_dt> Ah, yeah, not crazy
13:51 <abyrd> they were running raptor previously and it was quite slow but considering the novelty of this data set is that's not shocking
13:51 <abyrd> strikethough "is"
13:52 <abyrd> I figure with an even playing field (same linking strategy), raptor is likely to win
13:52 <novalis_dt> Probably.
13:52 <novalis_dt> Because it bounds the earch faster
13:53 <abyrd> I need to study your code anyway, so I'll contact you once I have more to say on the subject
13:54 <novalis_dt> OK, any time
13:54 <abyrd> but one thing that's going on here is that I threaded the bidi heuristic
13:55 <novalis_dt> Ah, neat
13:55 <abyrd> I realized you can actually use a partially filled in distance table if instead of reporting infinity for unreached nodes you report the highest known weight