Weekly check in 2011.10.20

• <demory> ok, why don't we get started
• <demory> i think this is everyone
• <novalis_dt> Status: I got the preliminary version of reach checked in, then checked myself out and started doing some of the other (non-OTP or non-TriMet) work I had been neglecting. I'm still trying to prove that my approach to reach will generalize to triangle routing, but I have a path forward on that when I get some free time.
• <demory> Great, thanks.
• <demory> I really don't have anything to report myself since Fri -- i've been in DC at Railvolution.
• <demory> Trimet folks, how have things gone since the launch?
• <mele> lots of positive feedback
• <mele> some specific things they're looking for, mostly ui
• <demory> ok
• <mele> we were talking to frank and dt about maybe a bike speed slider under custom
• <mele> or some other way users can change the time estimates for biking
• <demory> good idea. so are the requests like this being ticketed?
• <demory> i can do that if you forward me the info
• <Grant__> Also the two most common request from users so far have been printable directions (which I know Frank is working on) and the ability to modify routes by dragging and dropping
• <mele> we're keeping track but haven't ticketed any yet
• <andrewbyrd> my update: 1) checked in a proof-of-concept multi-objective routing service that correctly handles walk/transfer limits; 2) basic implementation of mode-specific turn restrictions based on OSM relations 3) caught the graphvertex refactor up to the main branch and did some more refactoring 4) trying out different ways to use a secondary search back from the target as a remaining weight heuristic
• • kpw has quit (Ping timeout: 265 seconds)
• <novalis_dt> Well, drag-and-drop is not happening any time soon, unfortunately.
• <demory> novalis_dt, what is the issue w/ drag and drop?
• <novalis_dt> demory, It's too compute-intensive
• <novalis_dt> On the back-end.
• <novalis_dt> andrewbyrd, is the multi-objective search slower? faster?
• <andrewbyrd> novalis_dt: about the same (half-second ish), but the results are different
• <novalis_dt> Given that it is actually correct, unlike our current approach, should we make it the default?
• <andrewbyrd> the really slow thrash trips, like biking from wilsonville to sand, are noticeably better
• <andrewbyrd> I'm pretty happy with it but as I'm still hacking on it, maybe we make it the default once I get this faster heuristic in place?
• <novalis_dt> The faster heuristic being the lower bound graph?
• <novalis_dt> er,
• <novalis_dt> the bidirectional
• <andrewbyrd> It allows for soft walk limits too, which will improve results
• <andrewbyrd> yes, the bidirectional, but using a decimated graph with less edges
• <novalis_dt> I'm actually a bit confused by that -- maybe after we hear from everyone else, you can explain it to me?
• <andrewbyrd> novalis_dt: sure. i did send you a short response to your email just a few minutes ago
• <demory> back to drag-and-drop for a sec: i see the issue when recalculating the route continuously as the marker is being dragged. But wouldn't it still be helpful to have draggable endpoints where the trip is only recalculated after the drag is completed?
• <novalis_dt> andrewbyrd, I read that, but I'm still confused; the reason there are multiple vretices at a given location is because of turn restrictions and penalties.
• <novalis_dt> Grant__, does demory's suggestion sound like what people are looking for?
• <Grant__> Not really
• <mele> it might help but i think what they really want is to drag the middle
• <mele> to get off one path and onto another that they know they like
• • kpw (d1b7fcfa@gateway/web/freenode/ip.209.183.252.250) has joined #opentripplanner
• <novalis_dt> Yeah, that is deeply not happening right now. Maybe, for bike-only trips, we would eventually do it
• <Grant__> They want to be able to grab points in the middle of a route so they can avoid particular areas
• <andrewbyrd> novalis_dt: yes, not sure how effective it's going to be yet. just as the heuristic works pretty well now even without accounting for transit schedules and waits, I think leaving out the turn penalties (which always increase weight) will not change much.
• <andrewbyrd> we can discuss later, I'm always interested in feedback too
• <novalis_dt> Oh, yeah, for a heuristic, you're right, of course.
• <mele> what about multi-destination routing for bike trips? we've had a request for that as well and it might get the dragging moving in the right direction
• <novalis_dt> That is supported in the API, actually.
• <novalis_dt> But it's supported in a funny way -- it does TSP rather than always doing A-B-C-D
• <mele> oh, interesting
• <novalis_dt> So if your locations are hillsboro, downtown, beaverton, gresham, it will do beaverton before downtown.
• <andrewbyrd> I think the drag-and-drop might be doable in realtime if we have a super-high-quality remaining weight heuristic that is retained for the duration of the user's session.
• • demory has quit (Ping timeout: 265 seconds)
• <mele> people generally know what order they want to visit places, though. maybe they need to go to downtown before heading back to beaverton
• <novalis_dt> Yes, that's true.
• <novalis_dt> And that would actually be an easier thing to support than what we currently have
• <andrewbyrd> I notice as the quality of the heuristic improves (more up-front calculation time) the time devoted to the actual forward searches tends toward zero. as it should.
• <novalis_dt> So if you ticket that, I'll go ahead and add it on the back end. Does that sound fair?
• <novalis_dt> andrewbyrd, sure, that makes sense.
• <mele> yep
• <novalis_dt> Demory, can you tell us about railvolution and any discussions there about OTP for analytics?
• • deomry (d1b7fcfa@gateway/web/freenode/ip.209.183.252.250) has joined #opentripplanner
• <mele> anyway we just wanted to make sure you guys were still thinking hard about dragging, since lots of people really want it
• <deomry> sorry, my connection was dropped
• <deomry> i would like to ticket these requests, even if they're still a ways off
• <novalis_dt> deomry, yeah, we have some of them ticketed
• <mele> can do
• <novalis_dt> Demory, can you tell us about railvolution and any discussions there about OTP for analytics?
• <deomry> sure
• <novalis_dt> I don't know if this an area TriMet is interested in, but it might be cool to demo on the Orange Line.
• • Grant___ (d819d3e9@gateway/web/freenode/ip.216.25.211.233) has joined #opentripplanner
• • mele_ (d819d2ea@gateway/web/freenode/ip.216.25.210.234) has joined #opentripplanner
• • kpw_ (d1b7fcfa@gateway/web/freenode/ip.209.183.252.250) has joined #opentripplanner
• <kpw_> sorry-david e and i are having network issues and keep getting disconnected
• • FrankX (1815504e@gateway/web/freenode/ip.24.21.80.78) has joined #opentripplanner
• <mele_> yeah i just got dropped as well
• <novalis_dt> Looks like all of the web users are having an issue.
• <kpw_> ah ok so it's an irc problem..boo
• <novalis_dt> I guess that means you guys are still out of the office.
• <kpw_> david e and are both in dc
• • FrankP has quit (Ping timeout: 265 seconds)
• • kpw has quit (Ping timeout: 265 seconds)
• • Grant__ has quit (Ping timeout: 265 seconds)
• <novalis_dt> kpw, cool. I hope you're showing off TriMet's new planner :)
• • demory (d03657e8@gateway/web/freenode/ip.208.54.87.232) has joined #opentripplanner
• <demory> sorry folks
• <demory> we're having some connection issues
• <kpw_> we have been--david's been demoing it, and talking about future possibilities with analytics
• <novalis_dt> np. We didn't actually hear anything you said, if anything.
• • mele has quit (Ping timeout: 265 seconds)
• <novalis_dt> Cool.
• <kpw_> meeting with the National League of Cities this afternoon
• • deomry has quit (Ping timeout: 265 seconds)
• <mele_> orange line stuff sounds fun to me, not sure whether planning will actually use it though
• <novalis_dt> mele_, yeah, I think they're already pretty far into the construction on that one
• <FrankX> Can't really do orange line...no schedule yet
• <novalis_dt> FrankX, well, if you know headways, you could fake something up.
• <demory> yeah, we've gotten some interesting feedback from these meetings. A clear interest in the safety aspect from NARC, we'll need to think about how that fits into analytics.
• <demory> what is the orange line?
• <novalis_dt> demory, TriMet's new light rail line
• <demory> is this a proposed expansion?
• <demory> ok
• <novalis_dt> It's under construction now -- not just proposed
• <mele_> i guess the idea is it could be used to help figure out schedules
• <mele_> ? or is it more just for where to put it
• <novalis_dt> Should be finished before the 2nd Avenue Line here in NYC.
• <novalis_dt> mele_, well, we hope to build tools to answer all sorts of questions like that
• <novalis_dt> And we think OTP could make a pretty good base for that.
• <demory> yeah whenever we talk about using OTP to help evaluate proposed system expansions it gets a positive response
• <demory> we're in discussions about doing that kind of analysis here in DC for the purple line, a new LRT line proposed in Md
• <demory> test
• <novalis_dt> That's maybe more practical, since it seems a bit earlier in the planning stage. Still, TriMet has such awesome people and technology that it's always worth trying to find new ways to collaborate.
• • PJ__ (d819d1da@gateway/web/freenode/ip.216.25.209.218) has joined #opentripplanner
• <mele_> there's always new stuff TM is working on planning
• <novalis_dt> Yeah.
• <demory> what kind of analysis would you want to do w/ the orange line?
• <novalis_dt> I just think it would be cool to do a couple of charts of reduced travel times from some of the areas that are served
• <demory> ok
• <demory> if we could put together a hypothetical schedule that should be doable
• <novalis_dt> Using frequencies.txt I think makes that a lot easier.
• <mele_> we could probably just approximate to mimic the other schedules
• <novalis_dt> Yeah.
• <mele_> all of the max lines here are pretty similar, i think
• <demory> are the alignment + station locations all set?
• <mele_> yep
• <novalis_dt> Oh, someone should update Wikipedia!
• <PJ__> ha
• <mele_> well they're not absolutely positively set but yeah they're set
• • mele_ has quit (Quit: Page closed)
• <novalis_dt> That makes things easier, yeah.
• <demory> good enough for our purposes
• • mele (d819d2ea@gateway/web/freenode/ip.216.25.210.234) has joined #opentripplanner
• <FrankX> Being the debbie downer one more time, it might be a fun project, but not a lot of reality. with the new max, existing bus routes will go away. what all that is, is anyone's guess
• <novalis_dt> Oh, that's true.
• <mele> it's true, bus routes will definitely change
• <mele> anyway http://trimet.org/pm/ has lots of alignment/station info
• <andrewbyrd> metro has some pretty sophisticated land use / transport models that are certainly taken into account when planning transit lines. in the long term we would need to get OTP serving as the route assignment phase in that kind of model.
• <mele> we were talking to one of the metro modelers at the preview actually and he sounded excited about making some comparisons between them
• <novalis_dt> Cool!
• <demory> yeah, the role for OTP as a supplement to traditional transport models has come up in several of our meetings here. there's definitely an opportunity there
• <novalis_dt> OK, so is there anything else we need to chat about? Or are we good to go, with the action items that mele will ticket the feature requests and I will write code to do multiple ordered destinations. Andrew will continue with optimization, and demory will work on the bike speed slider (the parameter is called walkSpeed, fyi).
• <mele> i think we're good. turn restriction mode exceptions are working great and we'll write up tickets for the new stuff
• <andrewbyrd> and if the new heuristic works nicely, i'll try to get it to cache its results to facilitate drag-and-drop rerouting
• <novalis_dt> andrewbyrd, that would be fantastic.
• • demory_ (d1b7fcfa@gateway/web/freenode/ip.209.183.252.250) has joined #opentripplanner
• • demory has quit (Ping timeout: 265 seconds)
• <novalis_dt> Cool. Talk to you all later, then (although you are of course free to hang out here if you like).