Weekly check in 2012.06.28

• 13:31 <demory> hi everyone
• 13:32 <demory> shall we get started?
• 13:32 <mattwigway> sure
• 13:32 <novalis_dt> Sounds good
• 13:33 <demory> great
• 13:33 <demory> my update: upgraded deployer to 0.7.7 which fixes the timezone bug for multiple-graph instances. Other than ongoing Deployer stuff, mainly working on batch processing of GTFS feeds off the Data Exchange for a potential North American OTP deployment
• 13:34 <novalis_dt> I've been generalizing OTP's routing and OSM graph building so that we can use it in the Cebu taxi tracking project. I also checked in an interesting zag removal fix; it turned out to be rather simple. I have no idea if it works correctly with elevation, because downloading NED takes 1,000 years.
• 13:35 <novalis_dt> Hm, I guess I could turn off transit, so that miniportland is smaller.
• 13:35 * novalis_dt tries that
• 13:35 <novalis_dt> Also some GTFS standards work.
• 13:35 <abyrd> I thought you guys had the entire NED database on a hard drive in NYC?
• 13:35 <novalis_dt> abyrd, I don't know where that HD is, actually. We do have it on S3, but when I tried to download it it timed out or something
• 13:36 <abyrd> Hm. I was kind of hoping to duplicate that NED disk when I'm in town.
• 13:36 <novalis_dt> We do probably still have it
• 13:36 <novalis_dt> And of course you would be welcome to
• 13:36 <novalis_dt> (I'm not in the office today so I can't look for it)
• 13:37 <mattwigway> novalis_dt, what's a zag removal?
• 13:37 <abyrd> I've been organizing/rereading all my references on isometric embeddings, trying to gain more insight on whether this can help speed up MOA* searches in big/complex graphs like we're starting to see in N europe
• 13:38 <abyrd> but mostly to write up a summary of my thoughts to pass on to Brandon
• 13:38 <novalis_dt> mattwigway, it fixes https://docs.google.com/drawings/d/1XH0PzgMAEMQKRq9fybqVA3-mDqc5OkSJbgKmA2IuIT4/edit
• 13:39 <novalis_dt> That is, the crappy narratives there
• 13:39 <mattwigway> thanks
• 13:39 <novalis_dt> I had been avoiding it because I thought it was going to be hard and fiddly; it was neither.
• 13:39 <novalis_dt> (famous last words -- we'll see how the NED goes)
• 13:40 <FrankP> My Update: I'm working to get rtp.trimet.org into shape to replace maps.trimet.org. This will be a good endurance test of OTP, in that we'll go from ~100 trip per day to 4000. http://maps5.trimet.org/otp.html ... working on Tiles at the moment. Was looking to upgrade OL to 2.11, since I need that to limit the first zoom layer to just Portland (as opposed to WW). Upgrading OL has revealed a few bugs in the vector drawing
• 13:40 <abyrd> other than that just working on using raster data sources in accessibility indicators
• 13:40 <novalis_dt> you got cut off after bugs in the vector drawin
• 13:40 <abyrd> and figuring out how I'm going to reconcile some differences between master and my branch with the transposed stop time tables
• 13:41 <novalis_dt> abyrd, someone was on earlier interested in GTFS Trip Update support
• 13:41 <mele_> the trails look good, FrankP, still want those service roads & tracks to be smaller/skinner though :)
• 13:41 <novalis_dt> abyrd, I guess your work is related but involves a different feed source
• 13:41 <abyrd> novalis_dt, did you catch their name?
• 13:41 -!- jcwon86_ [~[email protected]] has joined #opentripplanner
• 13:41 <novalis_dt> abyrd, yes, Nawaz Kurshid
• 13:41 -!- jcwong86 [~[email protected]] has quit [Read error: Connection reset by peer]
• 13:41 -!- jcwon86_ is now known as jcwong86
• 13:42 <novalis_dt> He or she was on as nawazk
• 13:42 <abyrd> well, I asked the guys in the Netherlands to produce a GTFS RT feed equivalent to their KV8 feed
• 13:42 <abyrd> so that I can support both
• 13:42 <novalis_dt> Awesome!
• 13:42 <abyrd> it should all be pretty pluggable
• 13:43 <abyrd> unfortunately since we don't store stop_sequence values (and GTFS allows them to be non-sequential) there is some fuzzy matching that needs to be done
• 13:43 <novalis_dt> Aargh, non-sequential stop_sequences
• 13:43 <abyrd> they already have the GTFSRT feed generator, I just need to ask them to switch it on to try out an implementation
• 13:43 <novalis_dt> We could store the mapping using TransitIndexBuilder if we felt like it
• 13:44 <FrankP> abyrd, is there a way in gtfs-rt to simply eliminate a trip? (or do you have to shut off all the stops as a re-route?) ... this is something TriMet will be very interested in next year at this time. And the easier we can strip out a trip, the better (e.g., missed pulls)
• 13:44 <abyrd> novalis_dt, yeah it's a pain. if you've got a message with a bunch of stop times, and there is a possibility that the route hits the same stop more than once
• 13:45 <novalis_dt> Right, of course. Makes more sense to store the mapping
• 13:45 <abyrd> it's just not clean
• 13:45 <abyrd> well, with KV8 we're OK because the stops are apparently already in order, so at worst you have to watch out for skipped stops
• 13:46 <abyrd> and most of the agencies use sequential, zero-based stop indices, except one
• 13:47 <novalis_dt> We should really set up a FAQ for OTP, by the way
• 13:47 <abyrd> we could store the mapping but that doubles the size of every stop pattern
• 13:48 <demory> novalis_dt, yes
• 13:48 <abyrd> well, they'd usually (?) be the same across all trips in a pattern I suppose so the array could be reused
• 13:48 <novalis_dt> abyrd, in the worst case, it could theoretically do worse than that.
• 13:48 <novalis_dt> But I think there are usually sensible compression mechanisms
• 13:48 <mattwigway> I've to run now, but I'll read the scrollback.
• 13:49 <novalis_dt> i.e. if they use block-sequential numbering, you could have a per-trip offset
• 13:49 <abyrd> yeah, there are many things to consider. I would prefer that stop seq numbers were just indexes into the list of stop times for a trip.
• 13:50 <novalis_dt> That would make sense
• 13:50 <abyrd> makes sense when you have two different feed types (GTFS and RT) referring to the same stop time entries
• 13:53 <demory> ok, any other updates
• 13:53 <demory> ?
• 13:54 <mattwigway> I haven't been doing much, but I'll be a lot more involved starting next week.
• 13:54 <novalis_dt> mattwigway, looking forward to it!
• 13:54 <abyrd> novalis_dt, I noticed that you were running into problems with the type system
• 13:54 <mattwigway> novalis_dt, me too!
• 13:54 <novalis_dt> abyrd, well, I guess I wanted multiple dispatch
• 13:54 <abyrd> is that becoming a real problem?
• 13:54 <novalis_dt> No.
• 13:55 <novalis_dt> It was just an irritating bug
• 13:55 <novalis_dt> It's hardly the worst thing about JAva
• 13:55 <novalis_dt> To be fair, I have never actually used a language with true multiple dispatch. It's just that you only notice the lack of it when it bites you.
• 13:57 <demory> if there are no other updates, i have a couple quick things..
• 13:57 <demory> first, if folks haven't read abyrd's post on Analyst at the OpenPlans blog, check it out: http://openplans.org/2012/06/27/visualizing-urban-accessibility-with-opentripplanner-analyst/
• 13:58 <demory> abyrd, do you mind if I cross post that to otp.com?
• 13:58 <mattwigway> btw, abyrd, that was an excellent intro to analyst
• 13:58 <abyrd> demory, no, go ahead and cross post
• 13:58 <demory> abyrd, thanks
• 13:59 <demory> actually, do you mind quickly setting up an account for yourself? http://opentripplanner.com/wp-login.php?action=register
• 13:59 <demory> i will upload the post, and will set you as the author
• 13:59 <abyrd> I was also thinking about sending the link to a mailing list (transit developers or something) to introduce people to Analyst
• 13:59 <demory> just want it to show up as you!
• 13:59 <demory> i'm hoping this can develop into a group blog of sorts..
• 14:00 <abyrd> demory, so this would require a separate account from the main openplans blog?
• 14:00 <demory> yeah, it's a separate system
• 14:00 <abyrd> ok
• 14:00 <novalis_dt> abyrd, speaking of improving A* performance... given that bus speeds depend on traffic speed, which is time-of-day dependent, might it make sense to adjust the A* heuristic's max speed based on the true max transit speed at the current time (based on a precomputed table bucketized by minute, say)
• 14:00 <demory> sorry
• 14:01 <abyrd> novalis_dt, I imagine that sort of thing could probably help tune the heuristic
• 14:01 <novalis_dt> abyrd, there's a primitive benchmarking tool, right?
• 14:03 <abyrd> well, I've got python scripts that will hit an OTP instance with a reproducible sequence of trips and make a violin plot of the response time distribution
• 14:03 <novalis_dt> Those in your github?
• 14:03 <abyrd> not sure whether the improvement would be worth the additional complexity... how much does max transit speed change throughout the day? isn't there always a bus running on a highway somewhere at 60MPH?
• 14:04 <novalis_dt> abyrd, maybe.
• 14:04 <mele_> you could take a look at the schedules to check on the variation
• 14:04 <novalis_dt> We could ask jcwong86.
• 14:05 <mattwigway> In the bay area, our reverse-peak express service is almost always running at 60MPH (I used to commute on it).
• 14:05 <novalis_dt> OK, so maybe this requires something more spatial, and then that is of course complicated.
• 14:07 <demory> oh. jcwong86, regarding gtfs processing, do you still need stats on how widely shape_dist_traveled is used? i could produce that pretty easily now
• 14:07 <abyrd> here you go: https://github.com/abyrd/OTPProfiler
• 14:08 <jcwong86> @demory let me get back to you. i'm thinking about general ways that agencies are using/creating their gtfs feeds to see how consistent they are. but its nothing of priority - just curiosity really
• 14:08 <abyrd> random.py is the most recent, but it's not configurable with command line parameters or anything, just edit the script
• 14:09 <novalis_dt> abyrd, cool
• 14:09 <jcwong86> @mele @novalis_dt is the question about what the distribution of bus speeds at any one time is?
• 14:09 <novalis_dt> jcwong86, yeah
• 14:09 <jcwong86> based on schedules?
• 14:09 <novalis_dt> Right.
• 14:09 <demory> jcwong86, ok, just let me know. I have a library of about 250 feeds now that could be easily scanned for that sort of thing
• 14:09 <novalis_dt> Actually, I bet those numbers vary based on distance
• 14:10 <jcwong86> I'm working on the speed between stops this afternoon actually. If I get that, we can select by hour and get a feel for the average speed in the system.
• 14:10 <abyrd> demory, speaking of this, when are we aiming to work on our profiling tools? I suppose I'll at least make the random endpoint generator in the next few days (that's simple enough)
• 14:10 <jcwong86> thing is... i bet there's a distribution within each hour based on number of type of bus service (local/express/limited stop)
• 14:10 <abyrd> no pressure though, I know we've got other things to do.
• 14:11 <novalis_dt> jcwong86, sure, but that's OK
• 14:11 <novalis_dt> We only care about the max speed anywhere in the system
• 14:11 <novalis_dt> Well, perhaps the max average speed depending on distance
• 14:11 <novalis_dt> That could be key.
• 14:11 <jcwong86> okay - i can work on that
• 14:12 <jcwong86> * i forgot about the time checks we were talking about last week, @mele. is that still something we want to explore?
• 14:12 <demory> abyrd, yeah, that sort of slipped due to the iOS / OTP North America stuff
• 14:13 <novalis_dt> jcwong86, I think it's not urgent, but if you get the chance to at least collect the data, that would be awesome.
• 14:13 <mele_> up to novalis
• 14:13 <mele_> yeah
• 14:13 <jcwong86> ok
• 14:13 <novalis_dt> Basically, I would really like bike times to match reality
• 14:14 <demory> abyrd, that may have to wait until that week we're in the NYC office together
• 14:14 <novalis_dt> Mele is one example, but one is probably better than 0
• 14:14 <abyrd> demory, sure. i was just kind of reminding myself what I needed to work on.
• 14:14 <mele_> i'm thinking what it might be useful for is getting a more realistic idea of slope speed vs. non-slope speed
• 14:15 <mele_> relatively
• 14:15 <abyrd> re: Astar speedup, I'm still hopeful that we can get the reverse search a lot faster
• 14:15 <mele_> 'cause yeah, i'm just one example :)
• 14:15 <abyrd> and possibly O(1)ish with some precomputation
• 14:16 <novalis_dt> Right.
• 14:16 <novalis_dt> abyrd, hm, interesting.
• 14:20 <demory> ok, if there's nothing else, i have one more housekeeping thing..
• 14:20 -!- mattwigway [~[email protected]] has quit [Ping timeout: 245 seconds]
• 14:21 <demory> i am out most of the next two weeks, will miss the next two check-ins. can someone please send me the transcripts?
• 14:21 <abyrd> demory, noted. i'll send them to you.
• 14:21 <novalis_dt> Sure.
• 14:21 <demory> thanks
• 14:21 <demory> actually will many people be around next Thurs? (its the day after 7/4)
• 14:22 <novalis_dt> I'm not planning on taking a vacation then.
• 14:23 <abyrd> yeah I'll be around as well
• 14:23 <abyrd> whoever is around can sync up and we'll just post the transcript
• 14:23 <demory> sounds great, thanks
• 14:24 <demory> ok, anything else for today?
• 14:24 -!- kpw [~[email protected]] has joined #opentripplanner
• 14:24 <novalis_dt> Nothing here
• 14:25 <FrankP> nothing here ... next week then.
• 14:25 <demory> alright. have a good week / holiday everyone!