Weekly check in 2013.03.28 - GeoSmartCity-CIP/gsc-opentripplanner GitHub Wiki
13:35 <demory> hey grant_h. we expecting Frank to join today?
13:36 <grant_h> No, he's on spring break w/ his family
13:36 <demory> ah, ok
13:37 <demory> well, i can give a quick update on what i've been working on
13:38 <grant_h> sounds good
13:38 <demory> so, one of my things for this week was to ticket up the various routing anomalies you all reported a while back
13:38 <demory> thing is, i can't seem to recreate them in a recent pull of master
13:39 <demory> (recent as in, the current last commit)
13:39 <demory> which leads me to wonder if maybe they've been resolved by the most recent work
13:39 <demory> i also can't recreate #945 on master, the transfer center bug
13:39 <nfn_> abyrd, i know that OTP uses Dijkstra and A* algorithms. I still doesnt see the code
13:40 <demory> i.e. it's doing what it's supposed to
13:40 <grant_h> hmm, the instance that Frank was testing on updates daily from master, but its been a few weeks since he documented those
13:41 <demory> yeah, i wanted to ask how recently he'd tried them against master
13:41 <demory> there have been a lot of routing-related commits in the last week or so
13:42 <abyrd> demory, thanks for trying to reproduce those bugs
13:43 <demory> ok, so the maps5.trimet.org instance updates from master daily?
13:43 <abyrd> interesting that they have been resolved... there were a couple egregious bugs fixed recently but I didn't imagine them causing the problems that were described
13:43 <demory> well let me double check that i haven't done something wrong on my end
13:44 <grant_h> demory: one of the instances we use for testing does
13:44 <abyrd> nfn_, the key question is how you are going to use users' evaluation of a full itinerary to affect routing calculations. that's not an obvious problem to solve.
13:45 <mattwigway> With regards to routing in Analyst, I'd also mention issue 990
13:45 <mattwigway> I'm not sure how soon I'll be able to work on it, but it's something to be aware of.
13:47 <nfn_> abyrd, the user classify the segments of an itinerary between 1(good) and 5(bad) for example. Then the system can use this rates to return the shortest path.. right?
13:50 <demory> so, i will keep trying to reproduce those routing bugs. on the front-end side, I'm working on an improved stop list / timetable viewer for trips. that will require some modifications to the TransitIndex API
13:50 <demory> variantForTrip seems to be completely broken in master right now, btw
13:50 <abyrd> mattwigway, thanks for mentioning and ticketing that. no pressure to get it fixed right away as long as we know it needs some work.
13:51 <demory> so i'm looking into that. eventually i want to add names to the stop info that's returned (currently it's just the id)
13:51 <abyrd> nfn_, but the quality of a segment of an itinerary is context-dependent. how could you use that information to influence completely different searches?
13:52 <nfn_> what do you mean with context-dependent?
13:53 <abyrd> demory, I've talked to several people who would like to see the transit data API grow a bit so they can use it instead of OBA in simple cases
13:53 <abyrd> so any improvements there are welcome
13:54 <abyrd> nfn_, I mean that the usefulness or quality of a sub-part of an itinerary depends entirely on which itinerary you are looking at. Just because a certain route is a bad choice for a given itinerary does not mean it is bad in all other itineraries.
13:54 <demory> yeah, i hear the same thing. at least for accessing basic static data
13:54 <abyrd> It is usually not the route/segment/edge itself which is bad, but some costing parameters that misrepresent the user's decision making behavior
13:55 <abyrd> I hear the same thing for real-time data as well :)
13:55 <grant_h> demory: we usually run a suite of tests each night on our instance that uses master and some of them were failing due to #945. It looks like test actually haven't run since late February (although I sometimes have issues with getting the test results page and cacheing)
13:56 <grant_h> I'll try to see if I can launch the tests manually and check if they're continuing to fail
13:56 <grant_h> with the new code
13:56 <demory> ok, thanks
13:58 <demory> i'll do some more experimenting on my end too
13:58 <demory> anything else for today?
13:58 <nfn_> abyrd, can you indicate a concrete situation where that's happen?
13:58 <mattwigway> should we talk about the PLC/Software Freedom Conservancy proceeding
13:58 <mattwigway> er, proceedings?
14:04 <abyrd> mattwigway, sure we need to finalize that
14:05 <abyrd> I am going to send out a proposed agreement to the list tonight since discussion has died down a bit
14:05 <mattwigway> I'd be in favor of the simple self-perpetuating committe
14:05 <mattwigway> er, committee
14:05 <abyrd> I was hoping to hear some support on the list for the point of view I expressed but no such luck
14:05 <mattwigway> which was that, sorry?
14:05 <abyrd> Yes, I think we should just do the simple self-perpetuating committee
14:05 <abyrd> with no limitations on who can participate
14:06 <abyrd> but with the understanding that this is a voting body that will influence how our IP is managed
14:06 <abyrd> and therefore should be composed of people who have had a stake in creating the IP
14:06 <mattwigway> right, you and David convinced me that we should have a minimum of requirements and that it should be primarily composed of developers
14:06 <mattwigway> (since it is an IP body)
14:06 <abyrd> developers, but also representatives of anyone who has invested time, money, or intellectually in the project
14:07 <abyrd> who are pretty much all devs right now
14:07 <mattwigway> although I'm in favor of no restrictions on membership per se, allowing anyone who has a role (as determined by the committee) to participate
14:07 <mattwigway> precisely what you said
14:07 <abyrd> I also agree with all the concerns about documentation and ease of use
14:07 <mattwigway> So I think SFC's first example paragraph is appropriate
14:08 <mattwigway> I agree with y'all that documentation/ease of use is a separate issue, though
14:08 <abyrd> but I think we should avoid the proliferation of "committees" and such bureaucratic structures
14:08 <abyrd> I am not against consultation with end users taking a more permanent form
14:08 <mattwigway> +1 on that
14:09 <abyrd> but these complaints are just surfacing now, with no attempt made yet to solve them in the "normal" manner
14:09 <abyrd> i.e. just participating in the collaborative creation process
14:09 <demory> abyrd, so would the initial composition of the PLC be the list you proposed last week?
14:09 <abyrd> before making committees we should first discuss issues on the mailing list,
14:10 <mattwigway> agreed, abyrd
14:10 <abyrd> and those who have had difficulties and have apparently made lots of notes can pass them on
14:10 <abyrd> we can talk by email or telephone with them and work together on the documentation
14:10 <mattwigway> incidentally, what's the time commitment of being a PLC member?
14:11 <abyrd> I see no need for a formal process but if people like to put a name on things we'll call it a consultation process and ask for input regularly on the list
14:11 <abyrd> reminding users that they are welcome to contribute
14:11 <abyrd> mattwigway, I think the time commitment is nothing more than voting when there's something to vote on
14:12 <mattwigway> ok, thanks
14:12 <abyrd> if all goes well, that should be quite rare
14:12 <abyrd> even this PLC is a formality -- things have funcitoned without it, but because OTP will basically become a division of SFC, we need a formal procedure for representing that division to its "parent company"
14:13 <abyrd> so it goes in writing...
14:14 <abyrd> nfn_, I was saying that this is always the case. people's judgement that a route is "bad" may have nothing to do with the GTFS data, and even if it did you wouldn't want to penalize routes because they happened to show up in what someone considers a bad trip plan.
14:18 <abyrd> nfn_, often routing problems involve a lot of human debugging to understand. the most useful thing for us would be a feedback feature that allows uers to indicate only when they think a route is bad
14:19 <abyrd> and then stores all the characteristics of the trip plan so a developer can dig into it
14:19 <abyrd> demory, yes I propose that list from last week for the PLC and also as the signatories
14:20 <abyrd> I will email everyone on the list and see if they want to join
14:20 <abyrd> mattwigway, I presume you will be both a signatory of the agreement and a PLC member?
14:20 <mattwigway> Yes.
14:20 <demory> ok, great. thanks for driving the discussion on this