Weekly check in 2012.11.15 - GeoSmartCity-CIP/gsc-opentripplanner GitHub Wiki
13:31 <grant_h> Hey guys, Frank and Mele are on vacation the next couple of weeks so they won't be joining today
13:32 <demory> grant_h, yep, they mentioned that last week. David T is still out too
13:33 <demory> so its probably just us and abyrd + kpw today
13:33 <demory> anyway we can still do a quick check in
13:33 <abyrd> hi everyone
13:34 <demory> i'm mainly working on the calltaker interface. hope to have something to show before the break next week
13:35 <abyrd> I had a call with grant_h and Mele about OSM review processes and they passed on a bunch of experience and documentation
13:36 <abyrd> we're going to present this to people here in Paris and try to get a community effort going to systematically verify data quality and compare with jurisdictional data
13:37 <abyrd> I've also been working on the analyst batch processor with some feedback from Jordan
13:37 <abyrd> and doing some profiler runs on various AWS instances
13:38 <abyrd> conclusion #1: despite recent improvements in memory consumption, running a NYC graph on an m1.medium is asking for problems
13:38 <abyrd> (though it almost works, even the graph build!)
13:39 <abyrd> Also prepping for a potential big project in the Netherlands
13:40 <demory> abyrd, wow, those performance visuals are great. are those automatically generated by the profiler?
13:41 <abyrd> I did these by hand looking for good angles
13:41 <abyrd> I think the automated results should include response time vs. trip length (since it's obviously correlated) and the log-log plots are informative
13:42 <abyrd> the data is pulled from a profiler DB but the plotting still needs to be scripted
13:45 <grant_h> I created GTFS for a couple ferry shuttles on the Willamette and got those up and running
13:48 <demory> actually, grant_h, i had a question about the calltaker interface
13:49 <grant_h> ok, sure
13:49 <demory> so, right now i'm working on the search history -- currently, there's a concept of a user (a calltaker) and searches are linked to a user in a database
13:50 <demory> so when a calltaker logs on w/ their username, they see a window w/ the last 10 or so searches they did
13:50 <grant_h> ok
13:50 <demory> of course, each time any option is changes, a new search is generated, and these can add up quickly
13:51 <demory> i'm wondering if we should introduce the concept of a 'call', with searches grouped by call
13:51 <demory> since a single call may include a dozen or so searches
13:52 <demory> that could make it easier if they're trying to pull up a search from hours earlier -- they would see a list of calls with times, rather than potentially hundreds of searches
13:52 <demory> and when they opened the history for that call, they would see the individual searches
13:53 <grant_h> sounds like a great idea to me, when the call takers are looking through the history its usually when a caller has phoned back in
13:53 <grant_h> this seems like it would make it much easier for them to retrieve the set of trips they're looking for
13:54 <demory> yeah, i think so. although, this means there would need to be some way in the webapp for calltakers to indicate a call is starting/ending
13:54 <demory> maybe just a 'call' widget with a start/end button?
13:55 <grant_h> Sounds good to me
13:55 <demory> ok, cool
13:56 <demory> this could also give you data on average call length, searches per call, etc. -- not sure if the call system already captures that or not
13:56 <demory> but all this will be stored in a db that can be used to generate reports, etc
13:57 <grant_h> not sure it the current system catches all of this, but it would definitely be a positive
13:58 <grant_h> I think the history capabilities will be a big improvement over what they're working with now if this works out
14:00 <demory> grant_h, great. also, one semi-related question -- when a calltaker "logs in" on the webapp, do you know if that needs to be authenticated with some external user database?
14:01 <demory> (for now, a user just specifies a username, no pw, that is used to tag their searches in the db. but i figured that might need to be made more secure/advanced)
14:02 <grant_h> not sure about that, I'll send out an email and get back to you
14:02 <demory> sure, no rush
14:02 <demory> ok, i think that's it for now, thanks
14:03 <grant_h> no problem!
14:03 <demory> anything else for the checkin? abyrd?
14:03 <abyrd> I think that's all for now.
14:04 <grant_h> oh, do either of you know where the ferry icons are called on with the OTP
14:04 <grant_h> within
14:04 <abyrd> oh, one other thing demory, do you handle the otp.org dns?
14:05 <demory> abyrd, no, not sure how that's set up. maybe check w/ anthony?
14:06 <grant_h> sorry meant, to say *within OTP's code
14:06 <abyrd> I was thinking it would be useful to have some symbolic names for the instances running profiler components to avoid using random ec2 names.
14:10 <demory> grant_h, not sure about the ferry icons. i can see them in the images folder, but don't see exactly where they are used
14:10 -!- inkybutton [[email protected]] has joined #opentripplanner