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