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