Weekly check in 2012.08.09

• 13:31 <demory> ok, let's go ahead w/ the check in then
• 13:31 <novalis_dt> I've been optimizing RAPTOR more. I've now got Southampton to the Bronx down to about a quarter of a second. Since New York is not so much of a challenge anymore, I've started expanding to Philly as well.
• 13:31 <novalis_dt> Also I fixed a few random bugs.
• 13:32 <demory> i've been focused mainly on the launch of bikeplanner.org, now live. this is the first deployment of the more generalized leaflet-based ui I've been working on
• 13:33 <novalis_dt> I really like the new UI
• 13:33 -!- FrankX [1815504e@gateway/web/freenode/ip.24.21.80.78] has joined #opentripplanner
• 13:33 <abyrd> yeah, looks good
• 13:34 <demory> novalis_dt, thanks! it's pretty similar in look/feel to the cibi.me one, but under the hood things are substantially different
• 13:34 <mattwigway> will/does that front end support transit as well?
• 13:34 <demory> this one should be easier to extend for other (non-bikeshare-specific) apps
• 13:35 <demory> yep, that's the next step
• 13:35 <mattwigway> neat!
• 13:36 <mattwigway> The only thing is a spot for a geocoder; I think many times people don't know on a map where they're going (especially if its somewhere they haven't been before)
• 13:36 <mele> +1
• 13:37 <abyrd> I've just been trying to get our automated API docs and Javadocs generation back in order
• 13:37 <mattwigway> demory: the first time I load up the page and plan a trip, instead of Quickest it says null in the triangle.
• 13:37 <abyrd> it's been several versions since they've been updated, due to some quirks in Enunciate
• 13:37 <abyrd> now that some of those have been fixed I can work around the others
• 13:37 <mele> plus it still says "safest" -- isn't all the code @ bike friendly now ?
• 13:38 <abyrd> other than that, this week I've been working on OTPProfiler (which will keep a database of performance characteristics so we can keep an eye on changes)
• 13:38 <abyrd> cleaning up rough edges in Analyst code for loading/saving various formats
• 13:39 <demory> mattwigway, good catch re the triangle. was just working on that widget earlier today.. should be a quick fix
• 13:39 <abyrd> and mulling over the different options for concurrency control when receiving streams of stoptime updates
• 13:40 <novalis_dt> abyrd, how's that going?
• 13:40 <abyrd> fine, it's just a matter of choosing an approach that will stand up to future change
• 13:41 <novalis_dt> Do your approaches allow binary search (or at least some sort of opimized search)?
• 13:42 <abyrd> that's somewhat of a separate issue, but since arbitrary updates are allowed, you'd have to just add an indexing layer on top of the stoptime tables
• 13:42 <mattwigway> demory, also, when I drag the start/end points the pickup/dropoff icons aren't hidden
• 13:43 <abyrd> I'm seriously considering centralizing all the stop time information, versioning, and indexing in a single index
• 13:43 <FrankX> demory, what's the url again...and repo url?
• 13:43 <novalis_dt> abyrd, yeah, that's not crazy
• 13:43 <abyrd> ie no decentralized pattern objects
• 13:43 <demory> FrankX, you mean for the leaflet ui stuff?
• 13:44 <FrankX> yes
• 13:44 <FrankX> (I got here late and didn't see the url)
• 13:44 <abyrd> board edges just say "considering what time it is, get me a departure on pattern P, and I'm working on graph version V"
• 13:44 <demory> the repo, for now, is https://github.com/demory/cibi.me
• 13:44 <demory> i want to move it out of my personal account though
• 13:45 <demory> also, bikeplanner.org is the current live deployment
• 13:45 <grant_h> demory: the way this version of the trip planner kind of plans trips on the fly makes me think implementing draggable routes (where is the middle of the trip could be modified by clicking and dragging) wouldn't be too difficult on something like this, is that the case?
• 13:46 <abyrd> novalis_dt, the big decision is whether it's acceptable to add a level of indirection even in the most common case where you aren't receiving updates
• 13:47 <novalis_dt> I don't think the indirection is the major pain point
• 13:47 <novalis_dt> I think it's the search.
• 13:47 <demory> grant_h, you mean intermediate points? i think OTP only supports that for walk/bike trips. but sure, that could be suported in this UI
• 13:48 <mattwigway> I've been working on compressing out transfer time in Analyst, building whole search trees that are reversed optimized.
• 13:49 <mattwigway> Which has been harder than it sounds, but abyrd and novalis_dt have helped a lot and I think I'm close.
• 13:50 <grant_h> demory: yeah intermediate points, but also with the ability to see how the route is modified (on the fly) as you move the intermediate point around on the map, google maps has this in their bike planner
• 13:50 <grant_h> and its something users request of us quite a bit
• 13:52 <mattwigway> it's harder with transit, but IIRC we discussed this once before and someone proposed having a fast calculation that just weighted streets with transit very low (i.e. preferred them) and then did a full trip plan when they drop the point.
• 13:53 <novalis_dt> Yeah, that's not crazy
• 13:53 <mele> we just haven't seen a UI implementation of intermediate points for even biking/walking over here, and we'd love to
• 13:53 <abyrd> mattwigway, that sort of reduces the feature to pure eye candy though
• 13:53 <mattwigway> I think you suggested it.
• 13:53 <mattwigway> yes, but once you drop it it's useful.
• 13:55 <abyrd> well I know people like visual cues, so I'm not saying it's pointless. Just that in terms of reliable information, updating the path only after you drop the pointer is about the same.
• 13:56 <mattwigway> true.
• 13:56 <mattwigway> But for a transit trip, you need more than just the map anyhow.
• 13:56 <mattwigway> actually, novalis_dt, with RAPTOR could we do full trip plans in real time?
• 13:57 <novalis_dt> Not yet
• 13:57 <novalis_dt> But I am making continuous speed improvements
• 13:57 <novalis_dt> My code change last night was pretty major, but for some reason, there's one trip that it actually makes worse
• 13:57 <mattwigway> how does it behave with the infrequent regional service case?
• 13:58 <novalis_dt> Very well
• 13:58 <mattwigway> nice!
• 13:58 <novalis_dt> Yeah, it's a big win
• 13:58 -!- janinge [~janinge@80.202.237.51] has quit [Quit: janinge]
• 13:59 -!- janinge [~janinge@51.80-202-237.nextgentel.com] has joined #opentripplanner
• 13:59 <demory> mattwigway, the "Quickest / null" issue is fixed now, thanks for catching
• 13:59 <mattwigway> sure thing.
• 13:59 <abyrd> novalis_dt, once you are happy with the performance, I'd like to use the Raptor branch to try out OTPProfiler
• 14:00 <mattwigway> also, with really long trips, clicking shared bike doesn't seem to work.
• 14:00 <demory> mattwigway, I'm having trouble recreating this one though: "also, when I drag the start/end points the pickup/dropoff icons aren't hidden"
• 14:00 <novalis_dt> abyrd, definitely. How is profiler coming?
• 14:00 <novalis_dt> I would love to use it locally instead of my current ad-hoc method
• 14:01 <mattwigway> so, if you have a shared bike trip, and drag the end, the route disappears but the pickup/dropoff don't until the new trip plan is returned.
• 14:01 <demory> oh, i see
• 14:01 <mattwigway> ok, that third one I just mentioned is working now.
• 14:01 <abyrd> I need to lower the total batch size as I mentioned (only try all permutations on non-random trips)
• 14:02 <abyrd> it will only support one graph at a time right now (I have endpoints coded for Portland)
• 14:02 <mele> mattwigway & demory : both disappear for me in firefox
• 14:02 <mele> when i start dragging
• 14:02 <mattwigway> it'd be neat if there was a way to plan a new trip without refreshing/manually editing the hash.
• 14:02 <abyrd> and there's no web (or other) frontend to make plots etc. but you can always do queries directly on the database
• 14:03 <novalis_dt> That's cool
• 14:03 <mattwigway> nothing disappears until I finish dragging or a new trip plan comes back in FF 13 on Ubuntu 12.04
• 14:03 <mele> oh nm now it's doing the same thing
• 14:03 <abyrd> novalis_dt, I'll try to have something more polished for beginning of next week
• 14:03 <mele> seems to go back and forth a bit
• 14:04 <novalis_dt> cool