Skip to content

2011.09.08 Weekly Check in

demory edited this page Sep 8, 2011 · 1 revision
  • 13:29 <novalis_> Good afternoon, everyone
  • 13:29 <demory_> hello all
  • 13:30 <demory_> shall we get started?
  • 13:30 <andrewbyrd> hi
  • 13:31 <andrewbyrd> sure
  • 13:31 <novalis_> I'm ready
  • 13:31 <demory_> well we've normally been starting w/ the trimet stuff -- Frank, you there?
  • 13:32 <demory_> otherwise there's other stuff we can cover
  • 13:32 <demory_> Frank
  • 13:33 <demory_> FrankP_: sorry, just let us know when you've joined
  • 13:33 <FrankP_> hey David, I'm here
  • 13:33 <demory_> oh, hey. great
  • 13:34 <demory_> so, let's do a quick update on the beta.. i don't have much to report.
  • 13:34 <demory_> i know there are issues w/ i.e. etc
  • 13:34 <novalis_> I've been working with the interns on various routing issues.
  • 13:34 <demory_> for the elevation stuff. i've just been focused on this demo for next week
  • 13:35 <demory_> i will try to set aside some time this weekend for elevation stuff -- both i.e. bugs and the graph builder stuff
  • 13:36 <demory_> sorry novalis_ -- anything of particular note to discuss regarding routing?
  • 13:37 <novalis_> Well, we have a couple of hairy issues: #477 and #492
  • 13:37 <novalis_> 492 is confusing to me; I thought I understood it, but I do not.
  • 13:37 <novalis_> I've asked Andrew to help look into it
  • 13:38 <novalis_> #477 is not at all confusing; it's a straightforward consequence of how we do street splitting for network linking
  • 13:38 <novalis_> But the fix is quite hairy; if anyone cares, I can post the diagram I sent Andrew.
  • 13:38 <andrewbyrd> novalis_ : right, I'm planning on seeing what I can do about these over the next couple of days
  • 13:38 <novalis_> Cool, awesome
  • 13:38 <FrankP_> My update: working on the UI the past few days, directions and alerts. Also working on OTP cluster behind IP-loadbalancer (I'm seeing OTP sometimes get hung for unknown reasons in test, and we also have the slow trips, so I'm a bit concerned there).
  • 13:38 <demory_> great
  • 13:39 <andrewbyrd> did you see the email I just sent you?
  • 13:39 <novalis_> I hadn't yet
  • 13:40 <novalis_> andrewbyrd, that seems much easier.
  • 13:40 <novalis_> And we can test it out at basically no cost.
  • 13:40 <andrewbyrd> novalis_ : and as a general approach it can solve some other quirks as well
  • 13:42 <andrewbyrd> to fill you all in, the routing engine finds ingenious ways to cheat and get around restrictions (turn restrictions in the ticket case, restrictions on sequences of trips in my case)
  • 13:42 <novalis_> OK, then #492 is still confusing, but we have a plan on #477
  • 13:42 <andrewbyrd> by taking shortcuts through stops and boarding/alighting trips
  • 13:44 <demory_> ok. i haven't looked at 492 so I can't add much there -- maybe after next Thurs
  • 13:44 <andrewbyrd> I won't go into detail I guess but refusing to traverse classes of edges in a certain order is equivalent to more complicated arrangements of vertices
  • 13:45 <andrewbyrd> I will still plan on looking at #492 then. I haven't yet reproduced and observed it.
  • 13:45 <demory_> great, thanks
  • 13:46 <demory_> anything more on 477/492?
  • 13:46 <demory_> if not -- FrankP_ going back to your update, is this hanging a new thing?
  • 13:46 <andrewbyrd> nope, I think we have a starting point for addressing them
  • 13:46 -!- kpw [43ddb10f@gateway/web/freenode/ip.67.221.177.15] has quit [Ping timeout: 252 seconds]
  • 13:47 <FrankP_> demory_, hard to say if it's new...it's just that folks (inters) are testing new things. In their testing, they've gotten OTP into a thread-lock a couple times.
  • 13:48 <demory_> hmmm
  • 13:48 <FrankP_> When I restart OTP, and run their test URLs, OTP is fine.
  • 13:48 <novalis_> I wonder if there's a garbage collection issue.
  • 13:49 <demory_> ok well keep us posted on that
  • 13:50 <demory_> again, i'll have more time to look into other stuff after next week
  • 13:50 <FrankP_> I did hook jvisualvm up to the remote server, and saw the trips that take a long time #352 have a staircase memory profile, which may indicate a memory leak after GC's, novalis_
  • 13:52 <novalis_> OK, so that's on the list to investigate
  • 13:52 -!- kpw [43ddb10f@gateway/web/freenode/ip.67.221.177.15] has joined #opentripplanner
  • 13:53 <demory_> ok so we have a couple things to look into
  • 13:53 <andrewbyrd> For these occasional very slow response times, which are generally due to slow secondary searches after a first itinerary has been found
  • 13:53 <FrankP_> If I find something repeatable (beyond #352), I'll ticket it...
  • 13:53 <andrewbyrd> as a stopgap fix GenericAStar does have a timeout option
  • 13:54 <FrankP_> andrewbyrd, timeout option...interesting. Do tell how I can activate that.
  • 13:54 <andrewbyrd> this is of course not a fix, but having it in place could save you some grief during the beta
  • 13:54 <FrankP_> yup...
  • 13:54 <demory_> yeah that would be better than nothing, esp if one itin has already been returned
  • 13:55 <FrankP_> Is there a way to turn that on via .xml config files?
  • 13:55 <andrewbyrd> currently it is a timeout on individual searches, but the path/routing services could progressively lower the timeout as itineraries are returned to bail out when things got out of control
  • 13:56 <novalis_> +1
  • 13:56 <andrewbyrd> often the end user would just see two itineraries instead of 3
  • 13:56 <andrewbyrd> and Frank could receive a log message telling us which trips were causing problems
  • 13:57 <novalis_> andrewbyrd, would Brian's multiple itinerary method avoid this issue?
  • 13:57 <andrewbyrd> I don't think it's configurable via XML now but it could be done
  • 13:58 <FrankP_> being about to control this would be cool. I'd probably set the timeout for 10-15 seconds maximum...the UI will time out in 30 seconds if no itinerary is back, so they get nothing now anyway.. And getting a log would help a lot.
  • 13:58 <FrankP_> Shall I ticket this?
  • 13:58 <FrankP_> (And honestly, I don't need XML control, if this was just default behavior).
  • 13:59 <andrewbyrd> I have been trying out Brian's method (to be fair to Brian, it's my method inspired by a discussion with him, so his in OBA may be more refined)
  • 14:00 <demory_> FrankP_ I think ticketing this is a good idea
  • 14:00 <demory_> ok well it sounds like we have strategies of some kind for the major issues.. anything more on Portland?
  • 14:01 <FrankP_> nothing more here...
  • 14:01 <novalis_> nor for me
  • 14:01 <andrewbyrd> It does work, but at least for the benchmark test cases is not faster than trip banning and is prone to producing technically correct but counterintuitive results
  • 14:02 <novalis_> It's not faster even in the worst cases?
  • 14:02 <andrewbyrd> unfortunately it is slower in the worst cases
  • 14:03 <novalis_> Alas.
  • 14:03 <novalis_> Well, we can put that on the back burner for now
  • 14:04 <andrewbyrd> and this is in the version where I'm progressively hashing tripIds so there's very little overhead from tracking trip sequences
  • 14:05 <demory_> agree w/ novalis_, it sounds like this probably isn't a realistic option for the Oct launch
  • 14:05 <demory_> but def somthing to keep looking into long term. thanks andrewbyrd for the update
  • 14:06 <andrewbyrd> right, not for oct.
  • 14:06 <demory_> well i can talk briefly about our presentation next week
  • 14:06 <demory_> Kevin and I are planning basically a four part presentation:
  • 14:06 <demory_> 1. general project history/background
  • 14:07 <demory_> 2. the Portland launch with demo of new features (bike triangle, improved narrative, etc)
  • 14:07 <demory_> 3. the data management tools we're developing for Atlanta
  • 14:08 <demory_> and 4. the analytics extension and isochrone test
  • 14:08 <demory_> I don't have much to add on #4 beyond the email I sent to the dev list earlier
  • 14:09 <demory_> but we should have something basic to show next week
  • 14:09 <demory_> i'll mainly be working on performance over the next few days. it really bogs down now over about 60 min max weight
  • 14:10 <kpw> but not because of otp, correct?
  • 14:10 <demory_> correct
  • 14:10 <kpw> that's primarily due to rendering of the result set
  • 14:11 <demory_> it's generating the polygon from the set of visited vertices
  • 14:11 <kpw> i'm curious if we can have otp generate a better structured result set that only includes "most distant" points
  • 14:11 <demory_> i'm using a pretty crude approach w/ JTS multipoints right now
  • 14:11 <demory_> the problem is that there are many redundant points
  • 14:12 <demory_> i'm sure there is an efficient way to do this, I just need to think this through some more
  • 14:13 <demory_> anyway we can keep that discussion going on the dev list
  • 14:13 <demory_> oh i did have one other thing about this
  • 14:13 <demory_> right now i'm working within the OTP codebase (in a branch) but I'd like split this into a freestanding project
  • 14:14 <demory_> like we described last week
  • 14:14 <FrankP_> +1
  • 14:14 <demory_> has anything happened w/ putting the current core OTP modules on a maven repo somewhere?
  • 14:15 <demory_> that's what we discussed right?
  • 14:15 <andrewbyrd> what I've done is generate or choose a set of sample vertices (a grid, via decimation, etc.) and only display or save weights from those
  • 14:15 <novalis_> That has not happened and it is my fault for not giving Andrew access to repo.opengeo until today
  • 14:16 <demory_> no worries, it's not high priority
  • 14:16 <andrewbyrd> well, I didn't send you an email asking for access until today either
  • 14:16 <andrewbyrd> OTP is basically already set up to do this
  • 14:16 <demory_> but once it's ready i will try to break out the analyst code
  • 14:17 <demory_> but I won't do anything there until Thurs at the earliest
  • 14:17 <demory_> well, if folks have any other input on the presentation, let me or Kevin know
  • 14:18 <demory_> and I'll keep you updated as we finalize the materials over the next couple days
  • 14:18 <kpw> also, curious to hear thoguhts on who else we should be talking with
  • 14:18 <kpw> this fall we'll be doing a "road show" of sorts for analyitics and we're making a list of interested parties/applications
  • 14:19 <kpw> just be thinking about ti
  • 14:19 <kpw> it
  • 14:19 <FrankP_> Speaking of talking...I might not be around next week. I'll be in Dever, FOSS4G.
  • 14:19 <kpw> great! say hi to the opengeo crew for us
  • 14:19 <demory_> yeah I had that for the end but let's discuss now
  • 14:20 <demory_> Kevin and I will be St Pete on Thurs too
  • 14:20 <demory_> our talk is that morning
  • 14:20 <demory_> should we just cancel the call? or try to reschedule?
  • 14:20 <novalis_> I am fine either way
  • 14:21 <demory_> if we reschedule it would have to be Fri for me
  • 14:21 <FrankP_> cancel makes sense for me, I won't be back till in the office till the 19th
  • 14:21 <demory_> ok let's cancel then
  • 14:22 <FrankP_> that said, I can hang out on irc
  • 14:22 <demory_> sure. but we won't do a call then
  • 14:23 <novalis_> OK, cool.
  • 14:23 <demory_> alright, the only other thing I had was this letter re the European Commission contest
  • 14:24 <demory_> i've been working today on the draft that was started a month or so back
  • 14:24 <demory_> i'm hoping to have something more polished before I leave NYC this afternoon
  • 14:25 <demory_> so the draft was written under Andrew's and Wojciech's names
  • 14:25 <demory_> is that still our plan?
  • 14:26 <demory_> we'll want to touch base w/ W too before we send
  • 14:26 <demory_> but if we're going to send something it should probably go out tomorrow
  • 14:27 <andrewbyrd> I guess we should leave my and Wojciech's names on it since we are the ones in Europe
  • 14:28 <demory_> ok. well I'll let both of you know once I've finished w/ my edits, hopefully within a couple hours
  • 14:28 <demory_> that's my main thing for this afternoon once the chat is finished
  • 14:29 <demory_> Andrew are you ok w/ actually sending it?
  • 14:30 <andrewbyrd> Yes, I will send it. Electronic version?
  • 14:30 <demory_> that's what I figured
  • 14:31 <demory_> i guess we could send a hardcopy too, though I would still do electronic so that they have something in hand tomorrow
  • 14:31 <andrewbyrd> OK, thanks for working on that. If you need to run today and want me to clean it up later, just let me know.
  • 14:31 <demory_> great, thanks
  • 14:32 <andrewbyrd> The page I am looking at states that the deadline is the 15th
  • 14:32 <demory_> really? i thought it was the 9th?
  • 14:32 <andrewbyrd> 15th of october even
  • 14:32 <demory_> i mean, it doesn't matter that much since we're not doing a full submittal
  • 14:33 <demory_> what page are you looking at?
  • 14:33 <andrewbyrd> http://ec.europa.eu/transport/its/multimodal-planners/take-up-the-challenge/index_en.htm
  • 14:34 <demory_> i see
  • 14:34 <demory_> now, if you open the .doc file under step 1 it still says 9/9
  • 14:35 <demory_> but I guess what is on the web is the most recent?
  • 14:35 <andrewbyrd> well we can just do it now if you have time
  • 14:36 <demory_> i may just send a quick email to that address to confirm
  • 14:37 <demory_> if it is in fact Oct 15, that could change things -- perhaps we'd be able to get the Pacific NW demo to the point where we could do a full submittal
  • 14:37 <andrewbyrd> true
  • 14:37 <demory_> let me follow up by email
  • 14:37 <demory_> and if it's in fact tomorrow, we'll just do the letter
  • 14:37 <demory_> it looks like they pushed it back though
  • 14:38 <demory_> ok, i'll follow up on that now
  • 14:38 <demory_> anything else for the chat?
  • 14:38 <andrewbyrd> thanks
  • 14:39 <FrankP_> 3 things quickly:
  • 14:39 <demory_> sure
  • 14:39 <FrankP_> Timeout: https://github.com/openplans/OpenTripPlanner/issues/502
  • 14:39 <FrankP_> kpw asked, who should we talk to? http://live.osgeo.org/en/index.html (Get OTP as part of this install)
  • 14:39 <FrankP_> Minor quibble: can we get http://opentripplanner.org/ to redirect to https://github.com/openplans/OpenTripPlanner/wiki/ (at least temporary?). I hate seeing the old site when I don't have the gitub url cached.
  • 14:40 <novalis_> That's not crazy. Any objections?
  • 14:40 <andrewbyrd> +1
  • 14:40 <novalis_> (I can do it right now)
  • 14:40 <demory_> you mean the web redirect?
  • 14:40 <novalis_> yeah
  • 14:40 <demory_> ok, great
  • 14:41 <demory_> i figured we'd have to talk to Evan about that
  • 14:41 <demory_> but if you have access, let's do it
  • 14:41 <novalis_> oh, hm. looks like we still have the API docs up on the old site
  • 14:42 <novalis_> I guess I could just rewrite some of the URLs...
  • 14:43 <demory_> well, can we just have otp.org (by itself) redirect to github but still have otp.org/apidoc online?
  • 14:43 <FrankP_> maybe have otp.org/index.html do a 303 over to https://github.com/openplans/OpenTripPlanner/wiki/
  • 14:44 <novalis_> I'm going to see what mod_rewrite magic I can do.
  • 14:45 <demory_> ok, great. btw, the new front page is still on my radar screen, it's just taken back seat to this talk next week
  • 14:45 <demory_> but it's still definitely a priority for the Oct launch and webinar
  • 14:46 <FrankP_> No worries about a new site, David...I just now hate seeing the old one.
  • 14:47 <demory_> yeah, i know. this is a good stopgap though, it may be another couple weeks before the new one is live
  • 14:47 <demory_> thanks for bringing it up
  • 14:47 <demory_> ok, anything else?
  • 14:49 <demory_> well i'll post the notes online
  • 14:49 <demory_> and no call next week, just usual coordination by irc/email
Clone this wiki locally