Weekly check in 2012.03.01

• 13:31 <demory> Hey everyone
• 13:31 <andrewbyrd> hi
• 13:31 <mele> Hi!
• 13:31 <mattwigway> Morning (or afternoon, I suppose)
• 13:31 <demory> let's start w/ our usual check ins
• 13:31 <demory> My update -- some additional testing/debugging of OTPSetup earlier in the week. Currently focused on the OTP system map work and integrating that with some stylized mapping/visualization work I've been doing on the side.
• 13:32 <novalis_dt> I've committed some changes to the elevation code -- we now interpolate elevation, and read OSM ele tags from nodes
• 13:32 <mele> Excellent! We've got to go get those bridge elevations now!
• 13:33 -!- grant_h [d819d323@gateway/web/freenode/ip.216.25.211.35] has joined #opentripplanner
• 13:33 <novalis_dt> Even without, you may get better routing
• 13:33 <novalis_dt> Because now bridges will not be assumed to be flat.
• 13:33 <novalis_dt> So, you won't take whichever bridge gains the most elevation.
• 13:33 <mele> hey grant dt was just saying that otp can now read ele tags from nodes
• 13:33 <mele> great
• 13:33 <novalis_dt> oh, I should close that ticket
• 13:34 <grant_h> ok, cool, I'm working to get the GPS unit ready to collect z values
• 13:34 <andrewbyrd> I just finished this batch query for San Francisco, and ended up making a custom fare calculation module.
• 13:35 <mattwigway> Be aware that elevation accuracy in GPS is generally very poor.
• 13:35 <grant_h> I'm planning to collect readings for the Morrison, Hawthorne, Sellwood, Ross Island, Broadway, Steel and possibly St. John's bridges
• 13:35 <mattwigway> Andrew, I think the new Muni GTFS includes fares.txt.
• 13:35 <andrewbyrd> Handling fare rules in multi-feed cities is pretty ambiguous, so I tried to make some of the default fare handling code reusable by subclasses that handle the local quirks in a given city.
• 13:36 <andrewbyrd> Yes, it includes fare info. But Muni alone isn't really the problem, since all the fares are 2 dollars.
• 13:36 <novalis_dt> Oh, I also added some code to the geometry checker.
• 13:36 <novalis_dt> Which is now useful for finding all sorts of bugs, and I highly recommend that everyone use it.
• 13:37 <andrewbyrd> It's more about what happens when a ride from another feed is in between two Muni rides on which you can use a transfer, or when alighting at a specific BART station gets you a free Muni ride, etc.
• 13:38 <novalis_dt> New York has some similar cases which I'm mostly not handling in the NYC fare service
• 13:38 <mattwigway> Yes, I wonder if we should note those types of things that require a clipper card? For instance, (at least downtown) Muni is 1.75 if you come off BART, but only if you are using Clipper.
• 13:38 <mattwigway> (Clipper = contactless smartcard for those unfamiliar)
• 13:38 <novalis_dt> Maybe add a fare alert field?
• 13:39 <novalis_dt> Or make the multiple classes of fare more formalized
• 13:39 <novalis_dt> (I think we sort of support it right now)
• 13:39 <kpw> i think multiple classes will eventually be important
• 13:40 -!- frankp [~[email protected]] has joined #opentripplanner
• 13:40 <novalis_dt> Yes, definitely.
• 13:40 <kpw> what's required to get there?
• 13:40 <mattwigway> Well, fares are a mess and I almost always ignore fare suggestions in other planners, because they can't take into account the unique combination of monthly unlimited passes, pass tokens, single rides, &c. that I use.
• 13:40 <andrewbyrd> Yes, a Fare can hold multiple fares for different classes, but there is not currently a card fare.
• 13:41 -!- frankp [~[email protected]] has quit [Client Quit]
• 13:41 <mattwigway> In many cases smartcard users may be versed enough in transit to know the fares, but in the Bay Area Clipper covers so many systems... someone from Santa Rosa/Golden Gate Transit likely does not know the rules about boarding and disembarking Caltrain, for instance.
• 13:42 <andrewbyrd> I was also thinking that just spitting out a number like $4.75 is pretty meaningless unless the user can see that this is made up of, say, $2.75 BART + $1.75 Muni discount transfer fare + Free Muni Transfer
• 13:42 <novalis_dt> So maybe each leg should have a fare?
• 13:42 <novalis_dt> Or it's more complicated than that because of transfers
• 13:42 <andrewbyrd> Without the detail they are unlikely to trust or understand the number given
• 13:42 -!- frankp [~[email protected]] has joined #opentripplanner
• 13:43 <kpw> could it be designed in a way that the custom fare calculator (what manages the transfer rules) could annotate the legs?
• 13:43 <kpw> so you get numbers and textual descriptions of the fare rules that apply?
• 13:43 <mattwigway> Especially with exact fare needed, &c.
• 13:43 <andrewbyrd> novalis_dt: it's much more complicated than that because rides may have to be chunked in different ways to get the correct optimal fare, as you addressed in the DefaultFareService
• 13:44 <mattwigway> I remember very distinctly buying a BART ticket once with a $20 bill at rush hour, and getting change in quarters...
• 13:44 <andrewbyrd> unfortunately that doesn't work right with multiple interspersed feeds
• 13:44 <novalis_dt> Yeah, but you have to pay each fare at some distinct time, right?
• 13:45 <novalis_dt> And GTFS actually addresses where fares are paid
• 13:45 -!- Peejay_ [ae199ddb@gateway/web/freenode/ip.174.25.157.219] has joined #opentripplanner
• 13:46 <mele> Maybe just a total would show initially but then it could be expandable, breaking fares up into each leg?
• 13:46 <andrewbyrd> right, there would be fare legs but they would potentially be different than the basic itinerary legs... but a fare leg would always be 1 or more itinerary legs. I suppose it would be fine to tag the itinerary leg where the fare is paid with a fare, and tag the subsequent ones with "free transfer" or whatever.
• 13:46 <andrewbyrd> mele: definitely
• 13:47 <novalis_dt> OK, andrewbyrd, can you ticket this proposal up so that we can implement it next time we have some time?
• 13:49 <novalis_dt> OK, does anyone have anything else they want to share?
• 13:49 <demory> anything else on fares?
• 13:49 <demory> I do -- I'd like to suggest the possibility of a new release (0.4.5?). This is partly for the benefit of OTPSetup -- it's currently on the latest snapshot (0.4.4) and is missing some important recent work -- e.g. the geometry checking, some fare calculation fixes, etc.
• 13:49 -!- frankp [~[email protected]] has quit [Ping timeout: 260 seconds]
• 13:49 <demory> in general I'd support moving toward a more frequent release schedule
• 13:50 <demory> any thoughts?
• 13:50 <andrewbyrd> novalis_dt: the algorithm in the default fare service is almost right for the general multifeed case if you set the cells for multi-feed ride sequences to +INF, but you lose the ability for free transfers after a leg from a different feed. I think I can make a truly general fare calculator that does a dijkstra search through all possible fare legs for an itinerary (it's a pretty small search space really).
• 13:50 <andrewbyrd> anyway, yes, I will tag it.
• 13:51 <novalis_dt> andrewbyrd, well, the current algorithm is lukas's change to my implementation of Google's algorithm
• 13:51 <mattwigway> My only concern with frequent releases is that we might have to maintain two code bases (e.g. the 0.4.x and master)
• 13:51 <novalis_dt> The latest version looked like Bellman-Ford to me.
• 13:51 <mattwigway> But in general sounds good.
• 13:52 <novalis_dt> I'm in general in favor of more frequent releases, so long as doing so doesn't entail much more bustwork for me.
• 13:52 <novalis_dt> busywork, even
• 13:52 <andrewbyrd> novalis_dt: oh, i didn't check who wrote that. yeah, it's Bellman-Ford, but I saw that Google does a greedy largest-prefix-with-a-fare method
• 13:52 -!- FrankP [c6e4dea7@gateway/web/freenode/ip.198.228.222.167] has joined #opentripplanner
• 13:53 <andrewbyrd> anyway it would be easy to just provide both alternatives
• 13:53 <kpw> i'm not sure we're talking about additional codebases, but rather more frequent snapshotting of progress
• 13:53 <novalis_dt> Anyway, we should also distinguish between the case where the ride is free, and where no fare info is available.
• 13:53 <demory> right. how stable is the current master? is there anything experimental we wouldn't want in a snapshot?
• 13:54 <demory> my concern is that w/ OTPsetup moving toward production we want to keep its copy of OTP relatively fresh
• 13:54 <novalis_dt> The current master has all of Andrew's recent changes, which I think are still broken on certain kinds of streets, right?
• 13:54 <demory> ..but without pulling from master haphazardly
• 13:55 <kpw> can we start to think about tagging releases, so that we can pull in changes more carefully?
• 13:56 <kpw> obviously master/head is going to be changing
• 13:56 <novalis_dt> In general, master is pretty stable, actually
• 13:56 <andrewbyrd> I'll cut a release whenever you need one. Though I think we're getting to the point that we may want to formalize the process a bit, like bugfixes only for a while (a week or so?) on a release branch before cutting it.
• 13:56 <kpw> yeah
• 13:56 <kpw> that would be ideal
• 13:57 <kpw> if we tag ahead of the release, run regressions against that tag
• 13:57 <kpw> and then apply fixes to the tag
• 13:58 <kpw> that would help ensure that ongoing work isn't breaking the release while we finalize it
• 13:58 <andrewbyrd> I'd say master seems stable (I just hit it with 20000 requests in a row before saying that), but the internals did change quite a bit recently. If you want to cut a release, I'll just concentrate on these turn conversion quirks for that release.
• 13:59 <demory> so do we want to create a release branch for 0.4.5 now?
• 13:59 <andrewbyrd> So when would you guys like to have a 0.5 for OTPSetup? In one week or 2? We can make a branch and set a date.
• 13:59 <mattwigway> When Andrew merged his changes there was some talk of a 0.5.
• 13:59 <kpw> ok, let
• 13:59 <kpw> oops
• 14:00 <andrewbyrd> The current version is called 0.5-SNAPSHOT so it is destined to be so.
• 14:00 <kpw> if we can shoot for 0.5 in a week, let's do that
• 14:00 <kpw> can we start tagging the tickets against those snapshots?
• 14:01 <kpw> so we can keep track of what's outstanding?
• 14:03 <demory> so that means having milestones for upcoming snapshots
• 14:04 <kpw> yeah, that should give us a venue for prioritizing tasks (bugs and features) by release
• 14:04 <andrewbyrd> There is now a 0.5 release milestone scheduled for next week.
• 14:04 <kpw> great!
• 14:05 <andrewbyrd> Shall we do regular releases every so often? Then we can just create a few of them and prioritize tickets.
• 14:06 <kpw> yeah, how about after every release we put up a 0.0.x release to catch near-term bugs
• 14:06 <FrankP> Would be
• 14:06 <kpw> and a 0.x release for next features
• 14:06 <kpw> and we can just bucket tickets into those milestones
• 14:07 <FrankP> Are binaries / .war part of a release?
• 14:07 <kpw> so next week we'd have 0.5.1 and 0.6 milestones on github
• 14:07 <andrewbyrd> If that helps people organize. It certainly helps me to have a feel for what phase of the cycle we are in -- adding new features or making sure a branch is stable for release.
• 14:07 <kpw> we'd also tag the code with those branches at the release point
• 14:08 <andrewbyrd> FrankP: If we are doing regular releases I think it would be good for first time users to just have a build of the latest stable release rather than trunk...
• 14:08 <kpw> so changes would get merged in based on tickets
• 14:08 <kpw> (does that make sense?)
• 14:08 <mattwigway> FrankP +1
• 14:09 <andrewbyrd> kpw: I was planning on using the maven release plugin as we have in the past, so tags would be produced as before
• 14:10 <kpw> ok
• 14:10 <kpw> does that allow us to keep the pending release branches separate from the master/dev work?
• 14:11 <kpw> can you explain how the plugin works?
• 14:13 <andrewbyrd> kpw: I have only used it on master, I will have to read up to make sure it supports releasing off a branch and merging with new artifact version numbers into master
• 14:13 <kpw> ok, just check and see what makes sense
• 14:14 <kpw> no need to complicate the workflow, but it would be great if we could have some mechanism for keeping development work in master from kludging up the release process
• 14:14 <andrewbyrd> if not, I will just start doing it manually. I'm not convinced it saves much effort.
• 14:14 <kpw> whatever accomplishes that is fine with me
• 14:14 <andrewbyrd> the release plugin i mean
• 14:14 <kpw> ok
• 14:16 <FrankP> .
• 14:17 <demory> anyone have anything else for today?
• 14:17 <novalis_dt> Nothing here!
• 14:17 -!- EvanCC [[email protected]] has joined #opentripplanner
• 14:17 <andrewbyrd> nope
• 14:18 <mattwigway> I wanted to ask what the status is on the shared Analyst SPT service?
• 14:19 <andrewbyrd> mattwigway: You mean running one server for OTP and Analyst, or just using calling general OTP search code from inside Analyst?
• 14:19 <mattwigway> The 2nd - basically the use of the same query strings/
• 14:19 <mattwigway> Eventually arrive-by is what I'm looking for.
• 14:19 <mattwigway> Not really concerned about #1 for now.
• 14:20 <andrewbyrd> #1 is not really a priority, but #2 is the next big step in Analyst
• 14:20 <andrewbyrd> let's say it won't be for the 0.5 release but the next minor version
• 14:20 <mattwigway> OK, cool. Can't wait to use it!
• 14:20 <mattwigway> Out of curiosity, does OP run an internship program?
• 14:21 <novalis_dt> mattwigway, you're a college student, right?
• 14:21 <mattwigway> Yep.
• 14:21 <novalis_dt> We definitely do!
• 14:21 <novalis_dt> Send Kevin an email and we'll talk.
• 14:21 <kpw> ([email protected])
• 14:22 <mattwigway> Kevin, David and I met at TranspoCamp West, you may (or may not) remember me.
• 14:22 <novalis_dt> I think I do.
• 14:23 <mattwigway> Cool! I'll send an email soon (maybe not till the weekend, after exams :)
• 14:23 <mattwigway> Thanks!
• 14:23 <kpw> great!
• 14:25 <demory> alright, I think we're done for today
• 14:25 <FrankP> Television care
• 14:26 <FrankP> TAke
• 14:26 <mele> haha frank
• 14:26 <mele> good day everyone!
• 14:26 <grant_h> tv care, (bye)
• 14:26 <Peejay_> byeeeeeee
• 14:27 <andrewbyrd> bye everyone