2012.12.06 Weekly check in

• 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:40 <abyrd> http://opentripplanner.nl/index.html#/submit&fromPlace=50.834775,4.335339&toPlace=52.516319,13.415196&mode=TRANSIT,WALK&min=QUICK&maxWalkDistance=20000&walkSpeed=1.389&time=08:36&date=29-11-2012&arriveBy=false&itinID=1&wheelchair=false&preferredRoutes=&unpreferredRoutes=&hst=true
• 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
• 13:56 <FrankX> BTW Dave, about Raptor -- we saw a lot of transit trips that just wouldn't plan with the trimet data when we ran our tests ... see http://maps5.trimet.org/otp-bugs/raptor/otp_osm_report.html (Graph and other stuff here: http://maps5.trimet.org/otp-bugs/raptor)
• 13:56 <novalis_dt> Yeah, all arrive-by trips...
• 13:57 <novalis_dt> There was a bug in the arrive-by code which made those not plan, which I fixed
• 13:57 <abyrd> meaning the table is still admissible at every point while the reverse search is being carried out
• 13:57 <FrankX> Okay....I'll try to get RAPTOR up and running again this week or next, and let you know...
• 13:58 <novalis_dt> abyrd, neat
• 13:58 <novalis_dt> FrankX, yeah, just wait until Avi fixes that issue or nothing will start
• 13:58 <abyrd> maybe we can even pull off some MOA* on these very long distance searches
• 13:59 <novalis_dt> If the network is good...
• 14:02 <demory> oh, one other thing for the check-in -- we had talked about an 0.9.2 release this week
• 14:02 <demory> are we ready for that?
• 14:02 <novalis_dt> Let's not until we fix some things
• 14:02 <demory> ok
• 14:02 <novalis_dt> Sorry, have had less time for OTP than I had expected
• 14:03 <demory> no rush
• 14:03 <grant_h> demory: I looked a bit further into the authentification issue for the call taker interface,
• 14:03 <demory> oh, right
• 14:04 <grant_h> FrankX pointed out that we'll probably want into to utilize employee's existing trimet uname and password
• 14:04 <grant_h> but we need to meet internally and figure out the requirements for this issue
• 14:05 <demory> ok. well initially the logging feature will be still be demo-able, just not tied to any existing user db
• 14:07 -!- mele_ [d819d11f@gateway/web/freenode/ip.216.25.209.31] has joined #opentripplanner
• 14:07 -!- mele [d819d11f@gateway/web/freenode/ip.216.25.209.31] has quit [Ping timeout: 245 seconds]
• 14:08 -!- FrankP [d819d3de@gateway/web/freenode/ip.216.25.211.222] has quit [Ping timeout: 245 seconds]
• 14:08 <demory> alright, anything else for today?
• 14:08 -!- FrankX [1815504e@gateway/web/freenode/ip.24.21.80.78] has quit [Ping timeout: 245 seconds]
• 14:08 <novalis_dt> nope
• 14:08 -!- grant_h [d819d4b7@gateway/web/freenode/ip.216.25.212.183] has quit [Ping timeout: 245 seconds]
• 14:09 -!- FrankX [1815504e@gateway/web/freenode/ip.24.21.80.78] has joined #opentripplanner
• 14:11 <mele_> sorry, I think the TriMet connection must have gotten iced
• 14:11 <mele_> we all lost it
• 14:12 -!- FrankX [1815504e@gateway/web/freenode/ip.24.21.80.78] has quit [Client Quit]
• 14:12 <mele_> I don't think there's anything else though, I'm sure Grant or Frank will email you about it if there is
• 14:12 <novalis_dt> Anyway, I think we're done for the day
• 14:13 -!- shaunmcdonald [~[email protected]] has quit [Quit: shaunmcdonald]
• 14:13 <demory> yeah, I think that's it for now, unless y'all had anything else
• 14:13 <mele_> cool, thanks
• 14:13 <demory> I'll be in touch later about the calltaker work in any case