Weekly check in 2012.10.04

• 13:32 <demory> mele, are we expecting anyone else from TriMet for the check-in?
• 13:34 <mele> you should be, i probably won't be able to participate much myself cause i'm at a conference
• 13:35 <mele> hopefully Grant & Frank will be in shortly
• 13:35 <demory> ok, thanks
• 13:35 <abyrd> demory, can you confirm for me whether we are using the graph builder annotations anywhere in deployer?
• 13:37 <demory> abyrd, not currently. though i was eventually hoping to add a feature allowing users to view them for their built graphs
• 13:38 <abyrd> so would it ever be important to load the annotations without loading the entire graph?
• 13:39 -!- brandonwillard [~[email protected]] has quit [Quit: Leaving.]
• 13:40 <demory> abyrd, i don't think so. under the current workflow the graph would be deployed on a host server anyway
• 13:40 <abyrd> I ask because I need to either move them to the end of the graph file
• 13:41 <demory> i want to set up an option for deployer to be used as a remote graph builder only, i.e. without deploying on a server. but that's more for experienced users who could download the graph and read the annotations locally
• 13:41 <abyrd> or separate them out entirely, replacing references graph objects with string or numeric IDs
• 13:41 <abyrd> the 50% decrease in memory use is just too good to pass up.
• 13:42 <abyrd> So in that case it makes sense to consider the annotations part of the DEBUG-level data and store them together.
• 13:42 <demory> yeah, smaller graph size would be beneficial in terms of deployer's aws usage
• 13:43 <abyrd> I'll just move them and we can split it out to a separate file if that presents problems in the future.
• 13:44 -!- FrankP [1815504e@gateway/web/freenode/ip.24.21.80.78] has joined #opentripplanner
• 13:44 <demory> ok, so they will still be a part of the file, they just won't be loaded into memory by default?
• 13:44 <abyrd> Several people working with large graphs (BeNeLux, Sweden) are suffering from extremely high memory use and this change should help address that.
• 13:45 <abyrd> besides it being just common sense not to load rarely-used debug data into RAM when it's half the graph
• 13:45 <demory> yeah, that makes sense
• 13:46 <abyrd> Yes, for now we can keep them in the Graph.obj. Like the vertex IDs we can stick them at the end of the graph. This is the only way Java allows partial deserialization to my knowledge.
• 13:46 <demory> ok, sounds good
• 13:46 <demory> well, why don't we officially start the check-in
• 13:46 <demory> this is probably everyone for today
• 13:46 <abyrd> Often you get millions of annotations, each with an Object[] full of Doubles... just wasted space in typical production use.
• 13:47 <demory> right
• 13:47 <novalis_> Checking in: I've made a bunch of misc bug fixes over the past week; that's mostly it.
• 13:47 -!- asutula [[email protected]] has quit [Quit: asutula]
• 13:48 <demory> My update -- workflow for pushing auto-generated deployer requests from data dashboard to graph builder and onto host servers is working, but as more are being pushed its revealing some bugs I'm having to work through.
• 13:48 <novalis_> I was thinking it might make sense to use Raptor for long trips and A* for short ones
• 13:49 <abyrd> I've been looking for low-hanging memory use fruit. Also trying some alternatives to get Analyst's notorious memory use under control.
• 13:49 <demory> novalis_, is there a problem w/ Raptor for shorter trips?
• 13:50 <novalis_> It's just not as fast
• 13:50 <FrankP> My update: I've been working to upgrad the TriMet map to use OpenLayers 2.12 ... have a problem with the print screen (no basemap tiles). Will then work to upgrade latest OTP .js code, and implement a few of the simple fixes (e.g., BIKE+TRAIN, etc...)
• 13:52 <FrankP> novalis_, also have a newer RAPTOR graph built. Was thinking to start a ticket, and put all feedback there...good, or do you want separate tickets, or to put feedback someplace else?
• 13:52 <novalis_> Separate tickets might make the most sense
• 13:52 <novalis_> That way I could fix them one-by-one
• 13:53 <novalis_> demory, want me to write to la metro about their feed error?
• 13:54 <FrankP> okay, sounds good...btw, first feedback is around multiple itineraries (I don't get many...and if I do, I get a variation on the first trip with same departure, but needless transfer in second option) ... is this good info for you?
• 13:54 <novalis_> FrankP, I would love to see specific examples of this.
• 13:54 <novalis_> FrankP, one known issue is that we never do later trips
• 13:54 <novalis_> There's already a ticket for that
• 13:55 <FrankP> okay, I'll try to repeat it and ticket it...
• 13:55 <FrankP> (ticket the needless transfer)
• 13:55 <novalis_> Does the needless transfer save time or walk distance?
• 13:56 <novalis_> Or is it just totally useless?
• 13:56 <FrankP> maybe slightly (0.05 mile walk), but it's more on the useless side of things
• 13:56 <novalis_> Presently, the walk saving threshold is 10%.
• 13:56 <novalis_> IIRC
• 13:57 <FrankP> stood out because the first trip was not banned, and thus reused...unlike the A* algo
• 13:57 <novalis_> Hm, maybe that's not right
• 14:01 <demory> novalis_, just saw the message about #847 -- first, when you say a vehicle stops at an entrance, you mean the entrance to a station?
• 14:01 <demory> and it also stops within the station itself?
• 14:01 <novalis_> Yes.
• 14:01 <novalis_> No
• 14:01 <demory> ok
• 14:01 <novalis_> I mean it stops at a stop with location_type=2
• 14:02 <novalis_> Which we don't create arrive/depart vertices for
• 14:02 <FrankP> .
• 14:02 -!- FrankP [1815504e@gateway/web/freenode/ip.24.21.80.78] has quit [Quit: Page closed]
• 14:02 -!- FrankP [1815504e@gateway/web/freenode/ip.24.21.80.78] has joined #opentripplanner
• 14:02 <novalis_> Anyway, I've got a work-around written
• 14:02 <demory> i thought location_type is only 0 or 1
• 14:02 <demory> or is that the problem?
• 14:03 <novalis_> demory, there is a proposal, pathways.txt, which allows for 2
• 14:03 <novalis_> To represent entrances/exits
• 14:03 <demory> ah, ok
• 14:03 <novalis_> weirdly, they're not using it
• 14:03 <novalis_> (that is, there is no pathways.txt file)
• 14:04 <demory> so, that feed is the product of the merge/transform process mattwigway set up -- we should confirm that the problem is also in the original feed
• 14:05 <novalis_> It almost certainly is
• 14:06 <novalis_> The stop is clearly labeled as an entrance in its name
• 14:06 <novalis_> However, it is possible that the transform process removes pathways.txt
• 14:06 <demory> yeah, double checking that now..
• 14:07 <novalis_> nope, there is no pathways.txt in the original
• 14:07 -!- grant_h [18166085@gateway/web/freenode/ip.24.22.96.133] has joined #opentripplanner
• 14:08 <demory> ok
• 14:08 -!- asutula [[email protected]] has joined #opentripplanner
• 14:08 <novalis_> FrankP, looking at the code, I see one thing that could conceivably be causing the issue; do the two trips arrive at precisely the same time?
• 14:08 <novalis_> FrankP, or should I just be patient and wait for the ticket?
• 14:09 <FrankP> yeah, let me find that trip (hopefully), and I'll ticket it...
• 14:11 <demory> novalis_, so yeah, it's probably worth letting LA know about that. in the meantime, will your workaround be included in 0.9.1?
• 14:12 <novalis_> I can pull it into stable
• 14:13 <demory> ok
• 14:14 <demory> abyrd, will you be building 0.9.1 off of stable?
• 14:14 -!- githubbot [~[email protected]] has joined #opentripplanner
• 14:14 -githubbot:#opentripplanner- [OpenTripPlanner] novalis pushed 3 new commits to master: https://github.com/openplans/OpenTripPlanner/compare/d689604a9a0f...1e9b92d72c7c
• 14:14 -githubbot:#opentripplanner- [OpenTripPlanner/master] fix #845 - novalis
• 14:14 -githubbot:#opentripplanner- [OpenTripPlanner/master] instead of banning non-car routes, simply give a bonus to car routes; this allows for trips that that in the middle of large parks but not reasonably-sized urban parks - novalis
• 14:14 -githubbot:#opentripplanner- [OpenTripPlanner/master] fix #847 - novalis
• 14:14 -!- githubbot [~[email protected]] has left #opentripplanner
• 14:15 <abyrd> we can do that however you want. master should be just a fast-forward away from stable at this point.
• 14:15 <novalis_> I'm kind of torn
• 14:15 -!- FrankP [1815504e@gateway/web/freenode/ip.24.21.80.78] has quit [Ping timeout: 240 seconds]
• 14:16 <novalis_> On one hand, I'm pretty sure that some of my fixes are necessar
• 14:16 <novalis_> y
• 14:16 <novalis_> On the other hand, some of them are a bit more questionable
• 14:17 <novalis_> Let's just be brave and merge master into stable
• 14:17 <abyrd> if you've got some you're not sure about yet, just cherry-pick the others into stable
• 14:17 <abyrd> ok
• 14:17 <novalis_> I'm equally unsure about not including thme
• 14:19 -!- brandonwillard [~[email protected]] has joined #opentripplanner
• 14:21 <demory> abyrd novalis_, so is the decision to go ahead and include all of the changes in 0.9.1?
• 14:21 <novalis_> Yep
• 14:21 <abyrd> that sounds fine to me, unless there is a commit you're particularly concerned about novalis_
• 14:21 <novalis_> I guess there is.
• 14:22 <abyrd> ok so we'll just fast-forward stable up to master and do the release off of it
• 14:22 <abyrd> wait, so there's one you want to leave out?
• 14:24 <novalis_> Yeah, let's skip d025d715db
• 14:26 <novalis_> by the way, abyrd, have you read http://research.microsoft.com/apps/pubs/default.aspx?id=145688 this one yet?
• 14:26 <novalis_> It might be worth implementing for our non-transit support
• 14:26 <novalis_> I don't think it does any good for multi-modal trips
• 14:27 -!- brandonwillard [~[email protected]] has quit [Ping timeout: 245 seconds]
• 14:27 <abyrd> no I haven't. that's on-street-only right?
• 14:28 <novalis_> Right.
• 14:28 <novalis_> But it would seem to support all of the flexibility that OTP offers.
• 14:29 <abyrd> always good to keep up on what delling et al are doing in case we can use parts of it. I'll read the paper.
• 14:31 <demory> alright, anything else check-in related?
• 14:31 <novalis_> Nothing here