Weekly check in 2012.05.10 - GeoSmartCity-CIP/gsc-opentripplanner GitHub Wiki
[10:34] <novalis_dt> kpw, seen demory?
[10:34] <kpw> he sent an email asking us to start without him if we want's back in time
[10:34] <kpw> let's begin!
[10:34] <novalis_dt> Ok! I just build an API for bikeshare info.
[10:35] <novalis_dt> And otherwise have been working on another project.
[10:35] <kpw> yay! we have dc planner that uses the bikeshare feeds: dc-bike.deployer.opentripplanner.org
[10:36] <kpw> we're working on the ui now
[10:36] <mele> awesome
[10:36] <kpw> but you can plan trips based on the docking station status
[10:36] <novalis_dt> Yeah, I've got to work a bit on the API response for bikeshare. I might do that this afternoon.
[10:36] <novalis_dt> And maybe fares
[10:37] == demory [a6890bb8@gateway/web/freenode/ip.166.137.11.184] has joined #opentripplanner
[13:37] <kpw> i'm curious about combining fare models
[13:37] <kpw> is that possible given the current design?
[13:37] <novalis_dt> Meaning, combining transit and bikeshare fares?
[13:38] <kpw> yes, by having two models that run against the graph
[13:38] <novalis_dt> I don't really know
[13:38] <kpw> so for nyc an NYCT model and a bike share model
[13:38] <kpw> the bike share model is reusuable
[13:39] <kpw> similarly for regional graph is might be nice to model each agency
[13:39] <kpw> so they could be reused
[13:39] <kpw> might be a longer-term question
[13:39] <novalis_dt> That is not in the general case possible, because agencies might have cross-fare deals
[13:39] <kpw> ah, yeah
[13:40] <demory> hey folks, sorry i'm late
[13:40] <demory> My update: mainly working on the dc bikeshare demo, including a new custom front end that I hope can evolve into a new "unified" OTP front end for the planner, analyst, visualizer, etc.
[13:40] <novalis_dt> I think I will see if I can figure out a good way to have both transit and bikeshare fare models, tho.
[13:40] <demory> also, sent out initial launch announcement to OTP list Monday -- plan a larger one in next week or so w/ some additional enhancements
[13:41] <abyrd> demory, just curious, have you seen a lot of instance requests after your announcement?
[13:41] <demory> no, just a couple
[13:42] <demory> perhaps we'll get more of a response after we send to transit-developers, etc.
[13:42] <kpw> i think we'll see more when we announce beyond the otp user community
[13:42] <kpw> (transit-devel, for example)
[13:44] == acochran [acochran@nat/openplans.org/x-iixvtcbjlxkdwhsu] has left #opentripplanner []
[13:44] <abyrd> I've just fixed a couple of bugs, and have been working on the analyst client
[13:45] <abyrd> and just deployed that bugfix release, demory
[13:45] == demory_ [a6890bb8@gateway/web/freenode/ip.166.137.11.184] has joined #opentripplanner
[13:46] <FrankP> TriMet update: we met with call agents (again) who plan trips via phone...they need a number of front-end features we'd talked about and ticketed before: a) next/first/last trip options, b) limit routing to bus line X (interesting twist is you just limit the first leg to bus line X), c) stop schedules and nearest routes, etc...
[13:46] <demory> abyrd, great, thanks
[13:47] <demory> FrankP, did you see my email earlier this week about the CUTR OTP webinar?
[13:48] <novalis_dt> I'm not sure what next/first/last trip really means, actually
[13:48] <novalis_dt> The next trip using the same sequence of routes?
[13:48] <FrankP> Yes novalis_dt ... at least the next trip on that beginning route
[13:49] <FrankP> (initial route)
[13:49] <novalis_dt> Hm. I'm wondering whether this is a planning problem or a transit info API problem
[13:49] <FrankP> demory, I did see your message, and was waiting on Bibi to reply...I went down and talked to here about a couple of things, and knew there was one I forgot...will be talking to her today.
[13:51] <demory_> FrankP, no problem, just let me know if she's interested in participating. I think CUTR wanted to have the speakers set by the end of this week
[13:51] <FrankP> demory, one idea (that's a bit off topic from what maybe the CUTR folks want) I had was around the power of an open source project. specifically, I'm thinking of the joy I had when I googled OTP in July 2010, and saw the Pune, IN version of OTP running. Could follow that up with the Isreal version, as well as the recent Dutch work...
[13:51] == demory [a6890bb8@gateway/web/freenode/ip.166.137.11.184] has quit [Ping timeout: 245 seconds]
[13:52] <novalis_dt> Plus the random guy on the mailing list who said he had like 70 instances
[13:52] <novalis_dt> Speaking of which, can someone get back to him about that multiinstance question?
[13:52] <novalis_dt> Because I have no idea about that.
[13:52] <FrankP> Is that the guy this week. Talking about Dallas (DART), then talking about Euro agencies?
[13:52] <novalis_dt> Yeah
[13:54] <novalis_dt> There was a question I could't answer, because I haven't really touched the multiple graphs stuff
[13:54] <demory_> FrankP, we can probably work something in about the international side at the end of the CUTR talk (more as a sidebar though)
[13:54] <novalis_dt> But maybe Andrew knows what's up
[13:55] <FrankP> novalis_dt...I've not touched the multi graph stuff either...but I do run multiple instances of OTP, and the UI can support talking to multiple instances with the purl=/<server relative instance>
[13:56] <FrankP> (this requires proxying with Apache, and using a single port where the UI runs off of)
[13:56] <novalis_dt> I don't actually know what this guy was talking about -- I mostly skimmed it
[13:57] <demory_> i've done some work with the multi-instance support (for deployer).. do you remember roughly when this was posted to the list?
[13:59] <novalis_dt> Oh, I see that Andrew has replied
[13:59] <novalis_dt> I guess I missed that
[13:59] <FrankP> abyrd, master Spring configurator :-)
[14:01] <novalis_dt> Anyone have anything else?
[14:02] <abyrd> Well, the multi-graph change was more a matter of plain old Java code intended to get rid of some Spring configuration...
[14:03] <abyrd> Nothing here.
[14:03] <FrankP> Routing / timing question (from call agents): from Origin to Bus stop is a 10 minute walk...the bus from this stop leaves at 9:00am...what time will OTP tell customer to leave their Origin and start walking (when doing a depart after trip...let's say the customer enters a depart time of 8:49am)? 8:50am? Or 8:45am?
[14:05] <FrankP> The question get's to the need (or their perceived need) to have 5 minutes of slack time at the bus stop...they didn't have an example, but thought OTP was planning trips too tightly, and would be cause for confusion / frustration by not giving the customer extra time to catch the bus...
[14:05] <novalis_dt> There is a parameter that controls that
[14:05] <novalis_dt> ... somewhere
[14:06] <novalis_dt> let me find it
[14:07] <demory_> oh, can someone please send me the first 10 min of the chat for the website?
[14:07] <FrankP> on it's way...
[14:08] <novalis_dt> minTRansferTime
[14:08] <novalis_dt> Defaults to 4 minutes
[14:09] <FrankP> thanks Dave...that's an API get param?
[14:09] <novalis_dt> Yeah.
[14:09] <demory_> got it, thanks FrankP
[14:11] <abyrd> FrankP, half of the minTransferTime is applied at each board or alight
[14:11] <abyrd> so transfers get 2x as much slack as initial boarding
[14:12] <FrankP> so if I'm understanding it correctly, with the default of 4 minutes, there's 2 minutes of slakc at that initial board?
[14:12] <abyrd> yes
[14:13] <abyrd> which is arguably too little... just letting you know that if you set it high enough to have 5 min of slack at initial boarding, you're going to get 10 minutes of slack at transfers
[14:13] <abyrd> because there are two vehicles involved
[14:14] <novalis_dt> Don't we have something in there for preferred transfers that avoids that?
[14:14] <FrankP> yeah abyrd...interesting...I'm not sure I'd want to jack the 4 minutes up much higher, but might want the initial leg to also have that 4 minutes
[14:14] <FrankP> definately wouldn't want 8-10 minutes of slack for transfers
[14:15] <FrankP> definitely
[14:15] <FrankP> or defiantly
[14:15] <abyrd> hmm, we could do that but as currently implemented it has to be symmetrical
[14:16] <abyrd> if you have 4min slack at the beginning, you'll also need 4min at the end
[14:16] <abyrd> to make the reverse optimize step work right
[14:18] <FrankP> if it becomes a cause for complaints, I'll jack it up to 8-10 minutes on our implementation, and then revisit the issue again here...good to know how it works, thanks...
[14:19] <grant_h> A interesting idea the call takers mentioned was including boarding times in the callout bubbles that indicate mode switches (the ones that contain the transit, bike, walk icons)