2013.03.21 Weekly Check in

• 13:33 <demory> FrankP grant_h abyrd, should we do a quick check-in?
• 13:34 <abyrd> hi david
• 13:34 <abyrd> sure
• 13:34 <FrankP> sounds good ... minimal stuff here ... just working on the text trip planner interface for TM
• 13:35 <abyrd> I'm getting ready to kick off the first sprint of our real-time project in the netherlands tomorrow
• 13:35 <abyrd> and we've been accepted by SFC so will be beginning a public discussion on the list about the development committee
• 13:36 <demory> abyrd, thanks for the email to the dev list, i think that summed things up very well
• 13:36 <FrankP> about SFC ... I see mention of the "initial signatories" for anyone who's contributed to the project. You need anything from contributers there? Or do you just put names down?
• 13:37 <abyrd> We should have as many major contributors as possible as signatories, and the committee structure is up to us as long as it has 3+ people
• 13:38 <abyrd> So while we're here, anyone who's interested in being on the committee let it be known.
• 13:38 <abyrd> I'm assuming at least David E, Frank, and I
• 13:39 <abyrd> Frank, are you up to representing TriMet's stake in the project on the committee?
• 13:39 <FrankP> I could be if that's needed.
• 13:39 <FrankP> BTW, you have my permission to add my name to that list. Not sure I want to be involved as an officer or committee member (my activity level wouldn't be very high, I don't think) or anything (but having my name on there would feel good)
• 13:40 <abyrd> It just means we'll ask you to vote when we make important decisions affecting the future of the project. It makes sense to have TriMet on there considering your huge role in the project.
• 13:41 <abyrd> If you think someone else would better represent TriMet just let us know.
• 13:41 <FrankP> No, I'm happy to play that role.
• 13:41 <abyrd> Great. What should we call the committee?
• 13:42 <abyrd> I know that sounds like a bikeshed issue but it's a variable in the agreement.
• 13:43 <FrankP> Can only come up with snarky titles at the moment...OTP Overloards
• 13:44 <demory> oversight committee? steering committee?
• 13:45 <demory> looking at other SFC projects to see what others use..
• 13:45 <FrankP> roadmap group (pun slightly intended -- road map / trip planner)
• 13:49 <demory> well, let's give it some more thought
• 13:50 <demory> my update for today -- not much to add to the email i sent earlier. let me know if there is any feedback on the geocoding piece. currently working on the enhanced timetable viewer and the field trip UI
• 13:53 <demory> regarding the back-end work -- grant_h, were you still planning to ticket the various problem trips/issues?
• 13:54 -!- githubbot [~[email protected]] has joined #opentripplanner
• 13:54 -githubbot:#opentripplanner- [OpenTripPlanner] abyrd pushed 1 new commit to master: https://github.com/openplans/OpenTripPlanner/commit/8b5b0a7d3dc266d5e5fee162e643581fa06bb878
• 13:54 -githubbot:#opentripplanner- OpenTripPlanner/master 8b5b0a7 Andrew Byrd: add comment on finalizer about temp edge removal
• 13:54 -!- githubbot [~[email protected]] has left #opentripplanner
• 13:54 <FrankP> I'm getting to the point of really wanting to upgrade the routing engine -- #945 is a major bug preventing the upgrade. But in addition to daylight savings bug (fixed in HEAD), a new strage one popped up yesterday. A customer sent in a bug report yesterday that exhibits very strange behavior in the old OTP code from October that we're running in production: basically, you need to increase walk distance
• 13:56 <grant_h> demory: yes, sorry about that, I meant to tell you all that I've been promoted to GIS Analyst so I have quite a bit more on my plate now and that's why I haven't gotten to it. I'm hoping to finish up a project I've been working on in the next couple of days and I should be able to get to it after that
• 13:56 <FrankP> ...for a trip between two max stations (Beaverton Central and Grasham Town Hall TC). You don't walk more than 1/4 a mile regarless, but the router won't plan the trip with the 1/2 mile walk or below...have to increase the walk the 3/4 or more
• 13:56 -!- githubbot [~[email protected]] has joined #opentripplanner
• 13:56 -githubbot:#opentripplanner- [OpenTripPlanner] abyrd pushed 1 new commit to master: https://github.com/openplans/OpenTripPlanner/commit/5e4f953201307b47f6eef70e72f2b35433a2abe0
• 13:56 -githubbot:#opentripplanner- OpenTripPlanner/master 5e4f953 Andrew Byrd: add error message when temp edges are not removed
• 13:56 -!- githubbot [~[email protected]] has left #opentripplanner
• 13:58 <FrankP> Anyway, yesterday's bug is fixed in HEAD, so it's a non issue...but yet another reason to move to a new routing engine sooner rather than later...
• 13:58 <demory> grant_h, congrats on the promotion! I'm happy to do the ticketing myself as long as everything is covered in those two emails Bibiana forwarded a while back
• 13:59 <FrankP> I'll submit those other issues today, since I think grant_h is a bit busy with another project.
• 14:00 <FrankP> spoke too late...demory, yes please submit the bugs ... it's all in the email
• 14:00 <demory> sure, will do
• 14:00 <demory> abyrd, have you had any luck w/ #945 yet?
• 14:00 <abyrd> FrankP sorry I got distracted with an email
• 14:01 <grant_h> thanks guys, I glad to ticket stuff in the future, just a bit busy right now
• 14:01 <FrankP> (And if I find some others along the way, I'll just add them to the issue list). Those new tickets, along with #945 are the tickets that we're most interested in.
• 14:02 <FrankP> (And when I say "we're", I mean me :-)
• 14:02 <abyrd> FrankP if I'm not mistaken you guys are using the RAPTOR code and I've never used that myself. I will of course be working on the reported issues but the simplest fix may be to just use the more heavily tested and used standard routing code.
• 14:03 <FrankP> Nope...no RAPTOR here. We tested it out for DT, but the bugs we're seeing are from the same config we've been using with the Dyk/A* stuff
• 14:03 <abyrd> Oh OK. Bad suggestion then.
• 14:04 <abyrd> Limiting walk distance at all is algorithmically incorrect unless accounted for in the dominance caluclations.
• 14:04 <abyrd> It will cause incorrect results.
• 14:05 <abyrd> That's a blunt way to put it because there are work-arounds to be found, but it's been a recurring issue since I first began working on trip planners.
• 14:05 <FrankP> BTW, here's our config stuff for the graph we're building with HEAD -- http://maps5.trimet.org/otp-bugs/osm
• 14:06 <FrankP> That config is responsible for the graph running here: maps5.trimet.org?purl=/osm
• 14:09 <abyrd> FrankP thanks for the links
• 14:09 <abyrd> I realize these issues are a priority for you, I've just got a bunch of things going on at once at the moment.
• 14:10 <deedubs> Hey guys, is OTP a good fit for a more 'continental' trip planner? f.e. long multi-segment road trips
• 14:11 <abyrd> hi deedubs, OTP can handle street routing quite well, but is designed especially for public transit multi-modal routing.
• 14:12 <deedubs> ah okay :/ thanks!
• 14:12 <abyrd> with the right setup, it has no problem routing on public transit across whole countries, but if you're really concentrating on street-only searches at continental distances that requires specific algorithms.
• 14:12 <FrankP> abyrd...no problem / understood. For the most part, we're okay floating the old code for a few months...but it's starting to get creaky (few recent issues, including yesterdays), so sooner the better, but we can wait a month or three...
• 14:12 <abyrd> take a look at OSRM
• 14:13 <deedubs> abyrd: Thanks a lot. Much appreciated!
• 14:14 <abyrd> FrankP, we would prefer to get you on the newest code within a few of weeks. Once this other project is started up we'll be back to allocating more time to coding.
• 14:17 -!- deedubs [uid2266@gateway/web/irccloud.com/x-xfspidrmrniysgvb] has left #opentripplanner
• 14:18 <demory> ok, anything else for today?
• 14:18 <abyrd> Nothing on this side.
• 14:20 <abyrd> Talk to you all later then!
• 14:21 <FrankP> None here. Getting fixes in before June sounds good to me. BTW, once I'm done with the text planner replacement (June/July), I am going to invest some time getting up to speed with debugging / fixing the backend...at least that's the plan...
• 14:21 <abyrd> Let's be more optimisic and say before May!
• 14:22 <abyrd> And FrankP once you're ready to dive in to the backend we can discuss any details that need clarification.
• 14:23 <FrankP> Thanks Andrew...I appreciate that offer.