Weekly check in 2012.06.21

• 13:31 <demory> hey folks, we ready to start the check in?
• 13:31 <novalis_dt> Sure.
• 13:32 <demory> great
• 13:32 <demory> my update: mainly working w/ kpw on a bikeshare OTP demo (similar to cibi.me) for CaBi system in Washington. in DC today for workshop on this later this afternoon. otherwise, busy processing deployer requests (lots of activity since last week) and related workflow issues
• 13:32 -!- githubbot [~[email protected]] has joined #opentripplanner
• 13:32 -githubbot:#opentripplanner- [OpenTripPlanner] abyrd pushed 1 new commit to master: https://github.com/openplans/OpenTripPlanner/commit/023a0812bca2e13d56df254eb74aa1434c81a1a4
• 13:32 -githubbot:#opentripplanner- [OpenTripPlanner/master] fixes #763: routerId param for component polygons, dummy routingcontexts - abyrd
• 13:32 -!- githubbot [~[email protected]] has left #opentripplanner
• 13:32 <novalis_dt> The major interesting thing I added was support for requiring a certain first transit stop on the trip.
• 13:33 <novalis_dt> This will be needed for first/last/next/prev trip
• 13:33 <novalis_dt> as defined in TriMet's requirements.
• 13:33 <jcwong86> Just picking up a task w/ @novalis_dt @mele about looking into bike speeds based on gps traces using... pdx graph i think.
• 13:34 -!- grant_h_ [18166085@gateway/web/freenode/ip.24.22.96.133] has joined #opentripplanner
• 13:34 -!- mele [d819d362@gateway/web/freenode/ip.216.25.211.98] has quit [Ping timeout: 245 seconds]
• 13:34 <novalis_dt> I also added convex hulls to the list of routers
• 13:34 -!- grant_h [18166085@gateway/web/freenode/ip.24.22.96.133] has quit [Ping timeout: 245 seconds]
• 13:34 -!- FrankP [1815504e@gateway/web/freenode/ip.24.21.80.78] has quit [Ping timeout: 245 seconds]
• 13:34 <novalis_dt> Which will be useful so that we can route requests to the correct instance
• 13:35 <novalis_dt> (I dusted off my Perl to write at tiny Perl module for nginx to do this)
• 13:35 <novalis_dt> Also fixed some bike rental bugs.
• 13:35 <novalis_dt> And did a bunch of stuff for Cebu, which entailed some tiny OTP changes.
• 13:36 <demory> oh yeah, once this workshop is over I'll be working on my piece of the multi-instance routing stuff
• 13:36 <abyrd> I just fixed the components NPE
• 13:36 <abyrd> will need to keep the tasks view open in Eclipse as it tracks any TODO/FIXME notes floating around in the source
• 13:36 <novalis_dt> Would be kind of cool if that were integrated with github issues
• 13:37 <demory> novalis_dt, sure, i'll ticket it
• 13:37 -!- FrankP [1815504e@gateway/web/freenode/ip.24.21.80.78] has joined #opentripplanner
• 13:37 <novalis_dt> demory, well, we're pretty unlikely to actually do this
• 13:37 <abyrd> I also now have an OTP module working that streams in KV8 data from all the Dutch transport operators and rewrites the stoptime tables accordingly
• 13:37 <novalis_dt> Although brandonwillard did say he was looking to get into Eclipse hacking...
• 13:38 <novalis_dt> abyrd, that's awesome.
• 13:39 <abyrd> replaced another excruciatingly batch of String.intern() calls on that branch, in the PBF loader
• 13:39 <demory> novalis_dt, sorry, what were you referring to w/ the comment about github issue integration?
• 13:39 <abyrd> that got graph building for the entire country of Holland down to 11 min
• 13:39 <novalis_dt> demory, the eclipse task list
• 13:39 <demory> (i thought you meant the pieces I'm working on for multi-instance routing)
• 13:39 <novalis_dt> demory, oh, no.
• 13:39 <demory> oh, ok
• 13:40 <abyrd> novalis_dt, there is a github integration module but I haven't tried it
• 13:40 <abyrd> Mylyn connector I believe it's called
• 13:41 <novalis_dt> abyrd, does that do TODO->github? or onyl the other way around?
• 13:41 <demory> that said, i should prbably still ticket the stuff i'm working on anyway -- but perhaps in OTPsetup rather than core OTP
• 13:41 -!- mele_ [d819d362@gateway/web/freenode/ip.216.25.211.98] has joined #opentripplanner
• 13:41 <abyrd> anyway I left the 0MQ/KV8 streamer running all night and the tables still look pretty coherent, no mem leaks
• 13:41 <novalis_dt> Excellent!
• 13:42 <FrankP> abyrd, was string.intern the main cause of slowness?
• 13:42 <abyrd> FrankP, yes. Just like in GTFS import, it works fine up to a certain size then grinds to a halt
• 13:43 <novalis_dt> And did you replace it with a home-grown version?
• 13:43 <abyrd> yep, same as we did for GTFS
• 13:43 <novalis_dt> Ah, I hadn't realized that GTFS one actually made it in
• 13:43 <FrankP> and here people were once advocating it...grrr
• 13:43 <abyrd> The silly thing is that the strings that are being interned are actually already pulled from a stringtable used for PBF variable width encoding
• 13:44 <novalis_dt> It's a good idea -- there's no reason why it should be slow.
• 13:44 <abyrd> but it looks like they make one string table per file block, so you get repeats anyway
• 13:44 <demory> btw, folks are beginning to show up for this workshop, so kpw and I are about to check out. please carry on though..
• 13:44 <abyrd> FrankP, advocating what?
• 13:44 <FrankP> Use of string.intern was seen as saving a lot of memory
• 13:45 <abyrd> it can, and internalizing strings is a good idea in many cases
• 13:45 <jcwong86> good luck @demory @kpw - have fun with that!
• 13:45 <abyrd> but the JVM apparently has an implementation that blows up over a certain number of strings
• 13:46 <abyrd> which makes no sense because it's a hashtable, and increasing the permgen size makes no difference
• 13:46 <FrankP> e.g, http://docs.oracle.com/javase/6/docs/api/java/lang/String.html#intern()
• 13:46 <abyrd> but empirically it blows up
• 13:46 <abyrd> so you replace it with a hashmap and it's way faster
• 13:47 <novalis_dt> One of the things I really like about Python is that the interpreter uses the same data structures as Python programs
• 13:48 <novalis_dt> So for instance every time the intepreter needs a resizable array, it uses PyList (I think it's called), which is the same thing as is used for lists inside Python programs
• 13:50 <novalis_dt> [end digression]. Anyway, anyone got anything else?
• 13:51 <FrankP> A quick update -- I tried to upgrade to OpenLayer 2.11 but have run into some problems. Will get back to looking at it today (back from a mini vacation).
• 13:51 <FrankP> We're currently on 2.9.x
• 13:52 <FrankP> Need some new stuff from 2.11 to limit the zoom layers, and start zoom layer 1 at what is now zoom #9 ... I don't want to make tiles for the whole world, just Portland.
• 13:53 <novalis_dt> Right, reasonable
• 13:54 <grant_h_> We're switching gears with the accessibility project
• 13:54 <FrankP> Very preliminary, but the problem might be with the elevation graph (I saw errors related to the south panel).
• 13:55 <grant_h_> the new plan (tentatively), is to review all streets tertiary and above and within one mile of a TriMet stop for the presence of a sidewalk
• 13:55 <grant_h_> and to tag them sidewalk=no if there isn't one present
• 13:56 <novalis_dt> And then forbid routing wheelchairs on sidewalk=no?
• 13:56 <grant_h_> not forbid, weight against
• 13:56 <novalis_dt> ok
• 13:57 <mele_> and probably for regular walking directions too to some extent, to keep people off of super busy streets when not necessary. but we're just starting to talk about it
• 13:57 <grant_h_> this would at least discourage "accessible" trips from going on streets w/o sidewalks
• 13:57 <mele_> so not sure yet
• 13:57 <mele_> super busy streets without sidewalks, that is
• 13:58 <novalis_dt> OK, that makes sense
• 13:58 <grant_h_> I ran a couple of queries and this will require us to review 20,000 to 25,000 segments (the data was in OSM Split format)
• 13:58 <novalis_dt> Ah, but it will probably be fewer ways
• 13:59 <grant_h_> but in most cases we'll just be scanning the data and taking no action (when the street has a sidewalk)
• 13:59 -!- kpw is now known as kpw_meeting
• 13:59 <mele_> yep, though we'll still be checking block by block
• 13:59 <grant_h_> yeah, definitely a lot fewer ways
• 14:00 <FrankP> \\\\\\\\
• 14:00 <novalis_dt> Hopefully you have some software support to make this easier?
• 14:00 <mele_> ...
• 14:01 <novalis_dt> I see.
• 14:01 <mele_> yeah... no.
• 14:01 <novalis_dt> Alas.
• 14:02 -!- kpw_ [~[email protected]] has joined #opentripplanner
• 14:04 <novalis_dt> Boy, kpw_, that testing was a good idea -- it already turned up a bug in the bike rental API.
• 14:05 -!- kpw_meeting [~[email protected]] has quit [Ping timeout: 244 seconds]
• 14:05 -!- githubbot [~[email protected]] has joined #opentripplanner
• 14:05 -githubbot:#opentripplanner- [OpenTripPlanner] novalis pushed 3 new commits to master: https://github.com/openplans/OpenTripPlanner/compare/023a0812bca2...6d21c9abc326
• 14:05 -githubbot:#opentripplanner- [OpenTripPlanner/master] multiple graph test for simple requests - novalis
• 14:05 -githubbot:#opentripplanner- [OpenTripPlanner/master] refactor and bug fix for bike rental API - novalis
• 14:05 -githubbot:#opentripplanner- [OpenTripPlanner/master] test for bike rental API and for multiple graphs - novalis
• 14:05 -!- githubbot [~[email protected]] has left #opentripplanner
• 14:09 <grant_h_> novalis_dt: We've debating whether we should delete the sidewalks that we have mapped since they're kind of screwing up the itinerary and we're not planning to use them now
• 14:09 <grant_h_> I'd rather not since I think they could be useful at some point
• 14:10 <novalis_dt> grant_h_, I might be able to fix the itinerary.
• 14:10 <grant_h_> ok, cool
• 14:10 <novalis_dt> If you can ticket it up, I'll look into it when I get the chance
• 14:10 <grant_h_> will do
• 14:13 <grant_h_> novalis_dt: I'd also like to get your take on our new plan of action for the accessibilty routing if your willing
• 14:14 <grant_h_> I'll send you a write up when we work out some more of the details next week
• 14:14 <novalis_dt> OK, sounds good.
• 14:14 <novalis_dt> It sounds to me like it might work well
• 14:15 <novalis_dt> But I'm not really sure.
• 14:15 <grant_h_> ok, I think getting away from trying to work with curb cuts is a good thing for now
• 14:15 <novalis_dt> Ok.
• 14:16 <novalis_dt> Did you get a chance to talk to any wheelchair users
• 14:16 <novalis_dt> about what would be useful for them?
• 14:16 <grant_h_> no, we need to do that
• 14:16 <grant_h_> I'll mention it to Bibiana, I think she can arange that
• 14:17 <novalis_dt> OK, excellent
• 14:17 <mele_> the small group we presented to were so excited about any improvement, but we didn't get much farther than that in the discussion. they had some input about what stop amenities were important
• 14:18 <novalis_dt> We can definitely contemplate stop amenities in routing
• 14:18 <novalis_dt> (given data)
• 14:22 <mele_> right, we have the data for that but we weren't sure when we'd have the funding to get it implemented. anyway the discussion is just getting going again so we'll keep talking about it in the future
• 14:22 <novalis_dt> Cool, thanks
• 14:24 -!- kpw_meeting [~[email protected]] has joined #opentripplanner
• 14:25 <abyrd> hey FrankP, you still around?
• 14:25 -!- kpw_ [~[email protected]] has quit [Ping timeout: 260 seconds]
• 14:25 <FrankP> novalis_dt .. we have stop amenities in our gtfs ... Mike G. has a proposal for an implementation, and stop_features.txt show his coded amenity types
• 14:26 <FrankP> abyrd, still here.
• 14:26 <novalis_dt> Right, it would be nice to know which ones people care about
• 14:26 <abyrd> I have noticed that the webapp does not seem to use the same paramter name for arrive-by searches as the api-webapp
• 14:26 <novalis_dt> & how much
• 14:26 <abyrd> is that intentional?
• 14:26 <mele_> we broke them up into categories based on our ideas & feedback
• 14:26 <mele_> kind of like stop rankings based on amenities
• 14:27 <abyrd> when you pass in the parameters in the URL
• 14:27 <mele_> i.e. a stop has all of these things, it gets top rating
• 14:27 <mele_> a few less, it gets a lower rating, etc
• 14:28 <FrankP> It probably derives from the old TriMet app -- where by=time implies an arrive by, and after= (or something like that) is depart after time
• 14:28 <FrankP> so one parameter x=time killed two birds
• 14:29 <novalis_dt> mele_, do you have a list of these categories?
• 14:29 <abyrd> "link to this trip" gives me &arr=Arrive
• 14:29 <mele_> let me see if i can dig that up for you
• 14:29 <abyrd> and the webapp reacts to that param
• 14:30 <mele_> there's the set from the original presentation that grant made, but i think we wanted to make a couple of changes to that
• 14:30 <FrankP> abryd, yea that looks like an older param. I can change things...maybe best to create a ticket, and assign me.
• 14:30 <abyrd> but api-webapp expects arriveBy=false
• 14:30 <abyrd> sure, will ticket
• 14:30 <grant_h_> page 6 on in this document summarizes the amenity classes https://docs.google.com/open?id=0B05QcW4SkYi4M3JGZ1JSbzFSa0NTNlBmNEVFeTJkUQ
• 14:30 <abyrd> thanks
• 14:31 <mele_> grant_h_ we wanted to move a couple things though, didn't we? do you remember which? I'm trying to find it in my notes...
• 14:31 <novalis_dt> And are those categories in GTFS?
• 14:32 <mele_> not yet, but presumably we can put them there
• 14:32 <novalis_dt> Ok
• 14:33 <grant_h_> mele_: Yeah, I couldn't remember if that version of the PPT was current, I have the updated version on my comp at the office
• 14:33 <mele_> the amenities are, right Frank? but not these categories yet
• 14:40 <grant_h_> Actually mele_ I think that is the most current version of what we discussed for the categories
• 14:41 -!- githubbot [~[email protected]] has joined #opentripplanner
• 14:41 -githubbot:#opentripplanner- [OpenTripPlanner] abyrd pushed 1 new commit to master: https://github.com/openplans/OpenTripPlanner/commit/b3d84d7d0e0ac2c26919031311e93062fe519d29
• 14:41 -githubbot:#opentripplanner- [OpenTripPlanner/master] rename analysis package internals (avoid confusion with analyst package) - abyrd
• 14:41 -!- githubbot [~[email protected]] has left #opentripplanner
• 14:42 <mele_> ok great
• 14:44 -!- githubbot [~[email protected]] has joined #opentripplanner
• 14:44 -githubbot:#opentripplanner- [OpenTripPlanner] abyrd pushed 1 new commit to master: https://github.com/openplans/OpenTripPlanner/commit/a0b92038056fbe36ae68ccdbcc99c61d9b19c0b3
• 14:44 -githubbot:#opentripplanner- [OpenTripPlanner/master] finish renaming packages (analysis -> internals) - abyrd
• 14:44 -!- githubbot [~[email protected]] has left #opentripplanner
• 14:48 <FrankP> the format of the .csv file is stop_features.txt is stopID,amenity_key
• 14:49 <FrankP> https://groups.google.com/d/msg/gtfs-changes/WRB5AgTA1bI/SuzpqXL1OZ4J
• 14:51 <FrankP> https://groups.google.com/forum/#!msg/gtfs-changes/czugweWClo4/1zdoR_1pf3YJ
• 14:52 <FrankP> finally, the definitive list of amenities' values: http://sites.google.com/site/gtfschanges/proposals/stop- amenity
• 14:52 <FrankP> http://sites.google.com/site/gtfschanges/proposals/stop-amenity
• 14:53 <novalis_dt> FrankP, let's see if we can get that into GTFS
• 14:53 <novalis_dt> officially
• 14:53 <FrankP> BTW, this data is currently in use by the Sendaro Brailnote app.
• 14:53 <novalis_dt> cool
• 14:54 <FrankP> (there might be other agencies who are also using this list, since I think multiple agencies are doing Brailnote via GTFS)