Weekly check in 2012.09.06 - GeoSmartCity-CIP/gsc-opentripplanner GitHub Wiki
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: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: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?