Skip to content

Weekly check in 2011.08.25

Andrew Byrd edited this page Dec 17, 2014 · 1 revision
  • [13:31] <demory_> hello all -- should we get started?
  • [13:31] <demory_> who all is actually here?
  • [13:32] <andrewbyrd> Hi
  • [13:32] <demory_> hi Andrew
  • [13:32] <novalis_dt> I am here
  • [13:33] <demory_> great
  • [13:33] <demory_> FrankP_, you there?
  • [13:33] <FrankP_> hey, yup here.
  • [13:34] <demory_> alright. looks like we lost Kevin but perhaps he'll rejoin later
  • [13:34] <demory_> let's start with the Trimet beta
  • [13:34] <demory_> I've been working on elevation / bike triangle suff this week
  • [13:34] <demory_> the bike triangle is checked in
  • [13:35] <demory_> let me know if you run into any issues with it
  • [13:35] <demory_> just curious, has anyone else tried it yet?
  • [13:35] <FrankP_> saw it...looks cool, demory_. does the router now accept the parameters it's giving?
  • [13:36] <demory_> yes
  • [13:36] <demory_> David T had that in place first actually
  • [13:36] <demory_> the results I'm getting seem to make sense
  • [13:36] <FrankP_> I'm going to make the triangle the default when choosing a bike / bike->transit trip. sound good?
  • [13:37] <novalis_dt> Fine with me. Andrew?
  • [13:37] <demory_> so is there any performace benefit to using one of the presets?
  • [13:37] <novalis_dt> Andrew is still exploring that, I think
  • [13:38] <demory_> i thought that was the reason for having the triangle be an option that is enabled only if needed
  • [13:38] <andrewbyrd> Sounds fine. I need to make sure this doesn't mess with the heuristic admissibility, but that was already on my mind.
  • [13:39] <novalis_dt> I've been working on a set of bugs around network linking and turns. It's slow going, but I hope I will get it done today or tomorrow.
  • [13:39] *** kpw (45fa9098@gateway/web/freenode/ip.69.250.144.152) joined
  • [13:39] <andrewbyrd> FrankP_ : just make it the default if you like and I'll aim to make the heuristics cope
  • [13:40] <andrewbyrd> novalis_dt: are you also seeing bike&transit trips not boarding transit? I figured that was just a side effect of the changes you were working on.
  • [13:40] <novalis_dt> andrewbyrd, not never boarding, but sometimes not boarding
  • [13:42] <demory_> also, i have been seeing some weird some results w/ bike only trips where safety = 100%
  • [13:43] <demory_> it will insert small walk segments in seemingly strange places -- e.g. walking the wrong way around a roundabout
  • [13:43] <demory_> then getting back on the bike
  • [13:43] <demory_> anyone else notice this?
  • [13:43] <novalis_dt> demory_, yeah, all of the strange results everyone has been seeing are because of this bug
  • [13:43] <novalis_dt> Or at least I hope so
  • [13:44] <FrankP_> We were seeing that, demory_. Dave's made progress to fixing that over the past week.
  • [13:44] <FrankP_> Also seeing bike trips start out with a small walk first (like 100 feet)
  • [13:44] <novalis_dt> There are some cases where that is reasonable
  • [13:45] <novalis_dt> In cases where it would avoid a maze of one-way streets
  • [13:45] <FrankP_> It's not in these cases, I think ... see issue https://github.com/openplans/OpenTripPlanner/issues/479
  • [13:45] <demory_> yeah. and i think that's related to the issue w/ the elevation profile not showing up sometimes
  • [13:46] <FrankP_> right. or just the small walk is rendered as elevation, and no bike is shown
  • [13:46] <demory_> i'm working on the elevation problem. should be easy to fix
  • [13:47] <demory_> but i'm also making some general enhancements to the elev code so it's taking a bit longer
  • [13:48] <novalis_dt> demory_, while you're at it, if you get a chance to figure out the too-steep street issue, that would be awesome
  • [13:48] <demory_> oh, yeah.
  • [13:49] <novalis_dt> I meant to take a field trip out to Valleyvue Ct with a plumb line, a level, and a protractor, but didn't get the chance.
  • [13:49] <demory_> that's more a graph builder issue though.. I'll take a look at it but probably after I finish this front end stuff
  • [13:49] <andrewbyrd> On my end, it is now possible to configure the heuristics via the application-context. Considering that we may want to allow complex choices about which heuristic to use, I used a pluggable factory class that should initialize and return whatever instance is relevant for the current trip.
  • [13:49] <novalis_dt> cool.
  • [13:50] <andrewbyrd> FrankP_ : I'm going to be updating the documentation explaning more about the WeightTable / Lower Bound Graph and how to set them up
  • [13:50] <FrankP_> looking forward to that, Andrew
  • [13:51] <andrewbyrd> As well as suggestions for the Trimet demo. I think the LBGraph is the most promising, but it needs work to be totally general (arbitrary bike speeds and such)
  • [13:51] <demory_> yeah i want to try that too w/ the Cascades demo
  • [13:52] <andrewbyrd> Anyway, I'll keep you posted. I've been a bit preoccupied with an upcoming third-year dissertation review, but will be working more on OTP this coming week.
  • [13:52] <FrankP_> my update: I've been filing a lot of bugs this week (and fixing a couple ... SAFE as default mode for biking...no TRIANGLE default). Also have a test framework where all our Issue URLs are executed. See: http://maps5.trimet.org/selenium/core/TestRunner.html?test=../otp/TestSuite.html
  • [13:54] <FrankP_> In the test suite, there's no validation being made...so you watch and see what the map is doing. It's been good for regression testing...
  • [13:54] <novalis_dt> OK, I really like that.
  • [13:54] <demory_> yeah that looks great
  • [13:56] <andrewbyrd> FrankP_, I've been looking at your chew trips and some of them are actually pretty quick if walk&transit mode is chosen.
  • [13:57] <FrankP_> A lot of those trips are much faster now, compared to the code from a few days back. Dave's improvements to the network linker may have helped?
  • [13:58] <novalis_dt> Hm
  • [13:58] <novalis_dt> I don't actually think there should have been a huge difference
  • [13:58] <novalis_dt> But the new network linkage is so buggy that numbers should not be relied on
  • [13:58] <novalis_dt> (aargh)
  • [13:59] <andrewbyrd> Looking into these stalled searches reminds me that it would be extremely useful to observe the search progress on a map. From what I've seen of JVM optimization I suppose callback hooks in the search method wouldn't slow things down when they were not in use.
  • [13:59] <FrankP_> This trip is still fairly slow though (it was 2 minutes, now it's 20 seconds): http://maps5.trimet.org/opentripplanner-webapp/index.html?fromPlace=45.29980542656,-122.77069645014&toPlace=45.379879699824,-122.2655217278&arr=Depart&min=QUICK&maxWalkDistance=7600&mode=TRANSIT,WALK&itinID=1&submit&date=08/25/2011&time=5:40%20pm
  • [13:59] <novalis_dt> Well, maybe I can get it back up to 2 minutes if I check in this change...
  • [14:00] <novalis_dt> Even if I don't get things working, I'll try to check in whatever I have before the hurricane hits..
  • [14:02] <novalis_dt> OK, what's next on the agenda?
  • [14:02] <demory_> so anything else for Portland?
  • [14:02] <novalis_dt> Oh, well, there's the GTFS-realtime stuff
  • [14:02] <demory_> if not, i'll give a brief update on the cascades demo
  • [14:02] <demory_> ok
  • [14:02] <FrankP_> Bug fixing is the biggest thing.
  • [14:02] <FrankP_> for Portland.
  • [14:03] <novalis_dt> FrankP_, have you had a chance to try out the GTFS-Realtime yet?
  • [14:03] <FrankP_> I started yesterday, and was working with the context.xml when I left off last night
  • [14:04] <FrankP_> I'll get the UI working with that today/tomorrow.
  • [14:04] <andrewbyrd> FrankP_: That search returns slowly here as well (about 8 sec) It's notable that the result does not use the WES rail or the bus to Sandy, as it's probably supposed to.
  • [14:05] <demory_> ok let's move on the cascades demo
  • [14:05] <FrankP_> On maps5 I get both wes and the bus. But it does take ~20 seconds.
  • [14:05] <demory_> oh sorry
  • [14:05] <FrankP_> no problem.
  • [14:06] <demory_> fwiw I got walk to Wes on that search. took a little under 20 sec
  • [14:06] <FrankP_> Is there a way I can help you guys to get OTP faster? Would you like stack traces or some other profiling data from OTP on this end
  • [14:07] <FrankP_> Or maybe the Weight Table stuff will help?
  • [14:08] <novalis_dt> FrankP, here's the chart of performance: https://github.com/openplans/OpenTripPlanner/wiki/Goaldirection
  • [14:08] <andrewbyrd> The trip URLs and graph builder configs are very helpful, should be enough for me to investigate some of this.
  • [14:09] <demory_> ok thanks. anything else on this?
  • [14:09] <FrankP_> Thanks andrewbyrd...let me know how else I can help...
  • [14:09] <andrewbyrd> Basically, those slow crunch trips should reveal the underlying problems, since they behave much differently (slowly) than the typical case
  • [14:10] <andrewbyrd> So demory_, is the Cascades demo too slow to be usable at present?
  • [14:10] <demory_> well here's my update on that
  • [14:11] <demory_> i did redeploy on a 64-bit install
  • [14:11] <demory_> that helped a little
  • [14:11] <demory_> but intercity trips are taking 10 secs + still
  • [14:11] <demory_> i don't think its memory issue
  • [14:12] <demory_> but i do want to try some other optimizations
  • [14:12] <andrewbyrd> If that's with no weight table / other A* heuristic being applied, the figures aren't too shocking since the search is just expanding outward in a huge circle across the west coast...
  • [14:12] <demory_> right
  • [14:13] <andrewbyrd> If we can get it to search reliably toward the destination it could work out well
  • [14:13] <demory_> so is the lower bound graph speed up configurable via xml yet?
  • [14:13] <andrewbyrd> I just checked in the basic machinery, but the heuristic itself needs to be made more general.
  • [14:14] <andrewbyrd> You can always try it out though and see how it performs in the mean time
  • [14:14] <demory_> ok. also rebuilding the graph w/ contraction heirachies enabled. that's running as we speak
  • [14:15] <demory_> so i'll let you know if either of these have an impact
  • [14:15] <demory_> also, did you want me to share any of the build graph files?
  • [14:15] <demory_> built, sorry
  • [14:16] <demory_> they are large -- the one i've built so far is about 600mb
  • [14:17] <andrewbyrd> If you grab 32c4562651e6b3bf5861 and look at api-webapp's application-context, you'll see a defaultHeuristicFactory bean that can be replaced with an LBGHeuristicFactory
  • [14:17] <demory_> ok thanks, i'll give it a try
  • [14:17] <andrewbyrd> I'll post docs on the wiki as it progresses though
  • [14:18] <demory_> great
  • [14:18] <demory_> well that's all I have for now on that. i'll keep you posted
  • [14:18] <andrewbyrd> If you can share your feeds and XML I will be testing performance on both Portland and Cascades
  • [14:19] <demory_> ok
  • [14:20] <demory_> so the other thing I wanted to cover was the analytics framework
  • [14:20] <demory_> basically, I'm hoping to get started on that next week, with hopes of having a very basic proof of concept ready for the St. Pete demo next month
  • [14:21] <demory_> i'm thinking isocchrone generation would be a good place to start, since it's come up on the list lately
  • [14:21] <andrewbyrd> Are you aiming for a 'transitshed' travel time raster?
  • [14:21] <demory_> yeah, essentially
  • [14:22] <demory_> tho perhaps vector not raster
  • [14:22] <demory_> i.e. "contour lines" showing waht can be reached in say 30 min, 45 min, etc
  • [14:22] <demory_> given a starting point and time
  • [14:23] <demory_> that's basically what they did in that paper
  • [14:23] <demory_> i was going to build something around Geoserver, it can help with some of the GIS ops
  • [14:24] <demory_> with a web-based front end
  • [14:24] <demory_> probably not a whole lot of configurability at first, just something that shows OTP can be used for this kind of work
  • [14:25] <demory_> so andrewbyrd is there any existing code i should be aware of?
  • [14:25] <demory_> i.e. to traverse the graph given certain bounds, etc.
  • [14:26] <novalis_dt> You can actually already set a max time on an A* search
  • [14:26] <andrewbyrd> The stuff I checked in recently was for a very specific application -- basically big-batch accessibility measurements using a population raster
  • [14:26] <demory_> ok
  • [14:27] <andrewbyrd> For the simple isochrone case, from a single destination, you can just reuse the A* or Dijkstra code
  • [14:27] <demory_> i'll take a closer look at the existing A* implementation
  • [14:28] <andrewbyrd> In fact, it looks like you could just use the Dijkstra class, since it has a weight limit parameter
  • [14:29] <demory_> ok. I'm more familiar w/ Dijkstra anyway. in any case it sounds like there may not be a lot of coding needed on the graph side then
  • [14:29] <demory_> at least to get something simple up and running
  • [14:29] <demory_> it will be more front end and Geoserver integration
  • [14:29] <demory_> again, I probably won't get to this until next week
  • [14:29] <andrewbyrd> The A* class currently does not accept null target arguments, and is really set up work toward a single goal and stop there, but could also be adapted
  • [14:30] <demory_> just wanted to run this by you all
  • [14:30] <demory_> ok thanks. I'll start out looking at Dijkstra
  • [14:30] <andrewbyrd> I think you will have an easy time using the Dijkstra class, then you can just read your travel time values right off the SPT object it returns
  • [14:31] <demory_> great
  • [14:31] <demory_> well hopefully i'll have an update for our call next week
  • [14:31] <novalis_dt> Of course, this is only at a specific time of day
  • [14:31] <demory_> right
  • [14:31] <demory_> that's all I wanted to focus on for now
  • [14:32] <novalis_dt> I actually just had an idea, speaking of that
  • [14:32] <novalis_dt> instead of having a separate optimisticTraverse method
  • [14:32] <novalis_dt> Have it as an OptimizeType
  • [14:32] <andrewbyrd> If you want the general case, ignoring schedules, you can just make a lowerboundgraph of your main graph, and call the SSSP method
  • [14:34] <demory_> ok thanks. support for the more general cases will probably come later but that's good to know
  • [14:35] <novalis_dt> FrankP_, I think I just fixed the network linker again
  • [14:35] <andrewbyrd> novalis_dt: sure, we could do that. it all depends if we want to make it possible to optimisticTraverse edges really fast, to avoid needing to do things like prebuild the LowerBoundGraph. If you've got ideas on the subject, we should definitely discuss on the list or wiki
  • [14:35] <novalis_dt> andrewbyrd, oh, yeah, really fast would be nice
  • [14:35] <FrankP_> Cool. I'll rebuild novalis_dt
  • [14:36] <andrewbyrd> In any case, I think this notion of optimistic graph traversal is going to be used a lot so we should consider the possibilities
  • [14:36] <novalis_dt> FrankP_, actually, there may be more bugs -- you never want to cross the river twice, right?
  • [14:36] <novalis_dt> Yeah, something looks screwy here
  • [14:37] <novalis_dt> shoot, I was so convinced that because I had fixed one bug, they all would go away
  • [14:37] <FrankP_> Generally not...but I've seen trips where you take the 14-Hawthorn back in & out of the city on ATIS too (not that that's the epitome of a good planner, but it's a baseline)
  • [14:37] <novalis_dt> That's actually what's going on here.
  • [14:38] <FrankP_> It's the walk at the begining of the trip that I'm troubled most with.
  • [14:39] <FrankP_> I thought that 14 looked pretty ugly, but ATIS gives the same trip as an option. On the UI, there's a link to see what ATIS would do, btw...
  • [14:39] <andrewbyrd> demory_ : one other thing when you're doing your isochrones. you may need to use the BasicShortestPathTree rather than the MultiShortestPathTree to keep search time within reason. Dijkstra already uses the Basic one, but it's configurable in A*.
  • [14:39] <novalis_dt> I use that sometimes, yeah
  • [14:40] <demory_> ok
  • [14:41] <demory_> so anything else for the chat today?
  • [14:41] <novalis_dt> Nothing here.
  • [14:41] <andrewbyrd> Nope
  • [14:41] <FrankP_> Does the idea to have a print version of OTP using Freemarker (rendered in a servlet) sound good to you all?
  • [14:42] <novalis_dt> Sure
  • [14:42] <novalis_dt> I would ultimately like a print version that was able to display a map
  • [14:43] <novalis_dt> But there's no rush on that
  • [14:44] <FrankP_> Printing and .js maps has been an issue for the 3+ years I've worked with OpenLayers. The solution is to "render things in the map server as a static image"
  • [14:45] <kpw> FrankP: jeff maki did some work with OpenLayers and printing for SoundTransit
  • [14:45] <kpw> and made some progress without needing to render static images (he used some IE v7 compatability mode workaround)
  • [14:45] <novalis_dt> I can send that workaround if you like
  • [14:47] <FrankP_> Yes, please do.
  • [14:49] <demory_> great. Frank anything else on your end?
  • [14:49] <novalis_dt> Well, I thought I could... if I can't find it I'll pester jeff again
  • [14:49] <FrankP_> nope. take care
  • [14:49] <andrewbyrd> talk to you all later
  • [14:49] <demory_> ok thanks everyone. i'll upload the notes shortly

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