Skip to content

Weekly check in 2011.09.08

Andrew Byrd edited this page Dec 17, 2014 · 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

The documentation on this wiki is outdated and should not be used

unless you are intentionally working with legacy versions of OpenTripPlanner. Please consult the current documentation at readthedocs

Clone this wiki locally