Weekly check in 2012.09.06

• 13:37 <demory> hey, sorry to interrupt, but should we go ahead and do our check-in?
• 13:37 <demory> kpw and I have another meeting after this
• 13:37 <novalis_dt> Yep!
• 13:37 <demory> great
• 13:37 <demory> my update: still focused mainly on changes to Deployer -- soon that workflow will be used not just for the trial instance requests but also the North America OTP app and abyrd's profiling work as well, so it's having to be reworked pretty extensively
• 13:38 <novalis_dt> I've been working on various RAPTOR fixes; also I ported the nginx plugin to Python but won't bother checking it in until I get the necessary info to add in dynamic reloading
• 13:39 <FrankP> I got RAPTOR running last night - http://maps5.trimet.org/?purl=/osm
• 13:39 -!- grant_h [d819d263@gateway/web/freenode/ip.216.25.210.99] has quit [Ping timeout: 245 seconds]
• 13:40 -!- grant_h [d819d263@gateway/web/freenode/ip.216.25.210.99] has joined #opentripplanner
• 13:40 -!- githubbot [~[email protected]] has joined #opentripplanner
• 13:40 -githubbot:#opentripplanner- [OpenTripPlanner] novalis pushed 1 new commit to master: https://github.com/openplans/OpenTripPlanner/commit/73d38a993c5c88afa572a800e4451625fdac4f00
• 13:40 -githubbot:#opentripplanner- [OpenTripPlanner/master] get correct trips for #824; still need to work out sorting - novalis
• 13:40 -!- githubbot [~[email protected]] has left #opentripplanner
• 13:40 <novalis_dt> FrankP, actually, would you be willing to restart that with the latest master?
• 13:40 <novalis_dt> (no need to rebuild the graph)
• 13:40 <novalis_dt> Sorry, but I realized that I had a regression
• 13:40 <FrankP> yea, will do right now...
• 13:40 <novalis_dt> Thanks
• 13:41 <abyrd> I'm working on blog posts and the NYC Analyst case study, measuring variance in profiler run times on AWS (and generally working out how it will fit into deployer), and some final changes for the dutch realtime support
• 13:41 <novalis_dt> The results are still a bit different than grant_h expects for #824, but I'll keep working on that.
• 13:43 <mattwigway> I'm generally working on OTP North America workflow and deployment management.
• 13:43 <mattwigway> I also checked in some major changes to car routing over the weekend.
• 13:43 <mele> Just wondering-- is there any reason why the "bike-friendly" bike routes should be different under RAPTOR than non-RAPTOR?
• 13:43 <novalis_dt> mele, for bike-only trips, no
• 13:43 <mele> The first thing I noticed was that I was seeing some things I didn't like
• 13:43 <mele> hmmm
• 13:43 <mele> I'm getting different results
• 13:44 <mele> Maybe it was a data change somewhere
• 13:44 <novalis_dt> That could be because of other changes
• 13:44 <novalis_dt> Including code changes.
• 13:44 <novalis_dt> RAPTOR is actually not used at all for nontransit routing
• 13:44 <mele> Yeah I'll see if I can sort it out or at least get some examples together
• 13:44 <novalis_dt> Is it wrong?
• 13:44 <mele> Ok, yeah that's what I thought, which is why I asked
• 13:44 <mele> It's not as good as it was in a couple of cases I've found so far
• 13:44 <mele> I'll test some more
• 13:45 <novalis_dt> OK, thanks. Can you also check to make sure it's not data changes?
• 13:45 <mele> Yep
• 13:47 <novalis_dt> OK, anyone have anything else?
• 13:47 <demory> novalis_dt, how close do you think we are to a release with raptor?
• 13:47 <demory> perhaps this should be 0.8.0?
• 13:47 <demory> it's a pretty significant change after all
• 13:47 <novalis_dt> demory, I'm concerned about the issues mele has pointed out
• 13:48 <novalis_dt> They're not related to RAPTOR, but they might be related to the graph refactor
• 13:48 <mattwigway> could be turn restrictions too.
• 13:48 <novalis_dt> mele, oh, also, previously some turn restrictions were being misapplied, and I have corrected this.
• 13:48 <novalis_dt> mele, so, please make sure that the old routes aren't making illegal turns.
• 13:48 <mele> okay, I'll keep an eye out for that kind of stuff, but my base test trips are generally ones I do all the time, so I know about the turn restrictions there
• 13:49 <demory> ok. part of why i ask is that at some point in the next week i should be ready to start building graphs on a large scale for the NA app. so if we're on the verge of a major new release i may want to hold off on that
• 13:49 <novalis_dt> demory, hm, that's rough
• 13:49 <novalis_dt> Can we do 0.8.0pre?
• 13:49 <novalis_dt> so that people know it
• 13:49 <novalis_dt> 's not stable
• 13:49 <demory> of course, automated OTP upgrading is a part of this new workflow
• 13:50 <mattwigway> demory, looks like we'll have 98 graphs.
• 13:50 <demory> that's just a lot more server time if we do a major upgrade quickly
• 13:50 <mattwigway> No, that's not right, we need to split NYC.
• 13:50 <demory> mattwigway, thanks. that's not too bad
• 13:50 <mele> FrankP , is http://maps5.trimet.org/otp.html?purl=/test#/ on the current OSM data and non-raptor code? or no? Would like to make sure it's set up that way so I can do an easy compare between that and the RAPTOR instance
• 13:50 <mattwigway> So if we split NYC into ~5, that's like ~102
• 13:51 <mele> or is there a better one to compare it with hiding somewhere?
• 13:51 <mattwigway> and we'll be rebuilding graphs a lot anyhow as GTFSes update.
• 13:51 <FrankP> ...
• 13:51 <demory> yeah, that's true
• 13:51 <mattwigway> and RAPTOR is I think necessary for this new workflow.
• 13:52 <FrankP> test is the latest 'stable' build of OTP, with newest .osm and .gtfs data
• 13:52 <novalis_dt> OK, so they're using the same OSM and GTFS?
• 13:53 <mattwigway> at least for NYC, SF, Portland, LA, Minneapolis, Reno, Seattle, Miami, Raleigh-Durham and Chicago, which are the top 10.
• 13:54 <mattwigway> also, demory novalis_dt, can we handle multiple bikeshare systems in the same graph?
• 13:55 <novalis_dt> mattwigway, yes, now.
• 13:55 <mattwigway> cool. Denver metro has two.
• 13:55 <demory> mattwigway, that's possible but it means restarting the instance, which isn't ideal
• 13:56 <demory> oh, i thought you meant multiple bikeshare-enabled graphs on a single OTP instance
• 13:56 <mattwigway> well, that's probably something we need to address as well.
• 13:56 <mattwigway> And also multiple GTFS Realtime feeds on the same instance.
• 13:56 <mattwigway> (or even on the same graph, but I don't think we have that yet)
• 13:57 <demory> yeah, that's on our todo list, see #825
• 13:57 <mattwigway> right, I saw it.
• 13:58 <mattwigway> so, demory, are you ready for some build requests with multiple GTFS for a single agency?
• 13:59 <mattwigway> wait, I guess we need to talk through merging.
• 13:59 <demory> mattwigway, yep
• 13:59 <demory> i don't have any of those three tools
• 14:00 <mattwigway> so, if you and or novalis_dt (or anyone who happens to be an OBA guru) could look over a change I made to the merger yesterday that seems to enable it to work, that'd be great.
• 14:00 <demory> it was reduce -> merge -> transform right? (not sure if I have the terminology totally correct)
• 14:00 <novalis_dt> mattwigway, link me and I'll take a look
• 14:00 <mattwigway> https://github.com/mattwigway/onebusaway-gtfs-modules/commit/a0d66b2778c60284c655e06b14e8cb26b6b09357
• 14:01 <mattwigway> novalis_dt, evidently calling trip.setId() leaves stop times orphaned.
• 14:01 <demory> mattwigway, maybe you can just send me the text of a sample request for now?
• 14:01 <demory> i.e. one with multiple feeds per agency
• 14:01 <mattwigway> I'm mainly concerned about the distinction of source/target
• 14:02 <novalis_dt> mattwigway, you mean around line 55?
• 14:03 <novalis_dt> Because I think we discussed that previously, and that looked correct to me
• 14:03 <mattwigway> demory, winging its way east now.
• 14:03 <demory> got it, thanks
• 14:03 <mattwigway> as usual, valid JSON attached as well as pretty-printed in the body.
• 14:04 <mattwigway> novalis_dt, no, I'm confident on the line 55 change (and it shouldn't have been in that commit, oops)
• 14:04 <mattwigway> What I'm wondering about is the overridden method.
• 14:04 <mattwigway> It overrides the generic one here:
• 14:05 <mattwigway> https://github.com/mattwigway/onebusaway-gtfs-modules/blob/a0d66b2778c60284c655e06b14e8cb26b6b09357/onebusaway-gtfs-merge/src/main/java/org/onebusaway/gtfs_merge/strategies/AbstractIdentifiableSingleEntityMergeStrategy.java#L201
• 14:05 <mattwigway> It'd be neat if GitHub was like Google Docs and you could see my cursor in the code.
• 14:06 <novalis_dt> Yeah, that would be great
• 14:06 <novalis_dt> I can see line 201 highlighted
• 14:06 <mattwigway> that's because I linked you straight to #L201
• 14:06 <mattwigway> (that is something cool that github does - if you click a line number, you get a link to that line)
• 14:06 <novalis_dt> OK, here's the question: how does context.getTarget().getStopTimesForTrip work?
• 14:07 <mattwigway> so, context.getTarget() returns a GtfsRelationalDao
• 14:07 <mattwigway> so does context.getSource()
• 14:07 <mattwigway> I think I want to change stop times in the target, because changing them in the source doesn't seem to make much sense.
• 14:07 <mattwigway> I haven't actually tried it though.
• 14:08 <novalis_dt> What I wish for on github was the full navigation I have in Eclipse
• 14:08 <novalis_dt> Go-to-definition, etc
• 14:08 <mattwigway> ctrl-o
• 14:08 <mattwigway> C-x 5 - 2
• 14:08 <novalis_dt> Yeah, I could also load up OBA-GTFS in Eclipse.
• 14:09 <novalis_dt> hm, looks like I already have
• 14:09 <mattwigway> right, only thing is this is in a fork.
• 14:09 <novalis_dt> Yeah, but I think what I'm looking for will be the same
• 14:10 <mattwigway> maybe I should try it with getSource, and if it doesn't work I'll have my answer.
• 14:11 <mattwigway> switching to my OBA workspace... just a sec...
• 14:11 <mattwigway> It seems to be faster with a new PSU.
• 14:11 <mele> grant_h did you need to ask novalis_dt about elevation stuff at all?
• 14:11 <novalis_dt> So, if OBA is reasonable, then your code will work
• 14:11 <novalis_dt> I have no idea if OBA is reasonable.
• 14:11 <novalis_dt> Have you tried it?
• 14:11 <mattwigway> Well, it does seem to work.
• 14:12 <grant_h> no, I think I'll be able to find a conversion
• 14:12 <novalis_dt> OK, then let's call it good
• 14:12 <mattwigway> But I haven't tried every possible case.
• 14:12 <mele> ok, cool
• 14:12 <mattwigway> anyhow, we can address that later.
• 14:12 <mattwigway> so demory, sorry for getting a bit sidetracked there.
• 14:12 <grant_h> but novalis_dt do you have some sort of conversion tool that you've been using to change the elevations in OSM to the same datum as the NED
• 14:13 <mattwigway> anyhow, with regard to the shorten/merge/transform process.
• 14:13 <mattwigway> so, shorten is a quick python script I wrote.
• 14:13 <novalis_dt> grant_h, no, I've never contemplated that at all.
• 14:14 <novalis_dt> Is there a standard on the datum for OSM?
• 14:14 <grant_h> yeah you're supposed to enter ele values in wgs84
• 14:14 <mattwigway> it gets called like shortenGtfs.py 20120804 in.zip out.zip
• 14:14 <novalis_dt> And what's NED in?
• 14:15 <grant_h> Not sure, but I think it's something other than WGS
• 14:15 <mattwigway> demory, should we jump into a private room, to stem two simultaneous conversations.
• 14:15 <grant_h> I'll research it
• 14:15 <mattwigway> grant_h, I think it's NAVD1972 or NAVD1980something.
• 14:15 <demory> well, is there anything else for the check in?