Weekly check in 2012.07.12

• <novalis_dt> I guess there's no demory -- he must be traveling.
• <mattwigway> morning (or afternoon, I suppose)
• <novalis_dt> Andrew and I have been working on various improvements to
• <novalis_dt> I've also been handling some bugs reported via the mailing
• <mattwigway> novalis, if you could give me an overview of that at some
• <novalis_dt> Be glad to
• <novalis_dt> There are three or four angles of attack that we have been
• <novalis_dt> Andrew has been looking into time-dependent SHARC
• <novalis_dt> This is hard because our schedules are way more complicated
• <novalis_dt> (which is why I did not implement it when I first read the
• <novalis_dt> Andrew also added in an improvement to how state dominance
• <novalis_dt> I have tried three things:
• <novalis_dt> (not in order)
• <novalis_dt> Cancel final transit trips if there are no stops on this
• <novalis_dt> This has failed so far, but I'm not 100% sure my code is
• <FrankX> I upgraded OpenLayers to latest 2.12...this broke two things:
• <novalis_dt> Precompute which street edges could be on transit-stop to
• <novalis_dt> This is worth about 10%.
• <novalis_dt> And I got about 40% by importing a bit from the default
• <mattwigway> 40% - wow!
• <novalis_dt> (Andrew's change was the big one -- it brought the
• <mattwigway> Do we know how it performs with large graphs yet?
• <novalis_dt> We don't.
• <novalis_dt> One problem with large-area graphs is that maxtransfers
• <novalis_dt> It might be up to 6 instead of the current 3.
• <mattwigway> oh, yep
• <novalis_dt> (that's 7 / 4 boardings)
• <novalis_dt> But we could do a "local" notion of maxtransfers
• <novalis_dt> Meaning that within an urban area we would only allow 3
• <novalis_dt> And then when you get on to the long-distance transit, your
• <mattwigway> Out of curiosity, how did you arrive at the three transfer
• <novalis_dt> mattwigway, via the anus
• <novalis_dt> It looks about right for Portland
• <FrankX> We were at two...found a trip around Portland that needed 3
• <mattwigway> I can definitely think of three and four transfer
• <novalis_dt> mattwigway, meaning five-vehicle trips?
• <mattwigway> yep.
• <novalis_dt> Yeah, that's not surprising.
• <FrankX> But is >3 transfers something that a customer would really do?
• <mattwigway> Over multiple agencies, perhaps
• <novalis_dt> Keep in mind that the only time that the transfer limit
• <FrankX> Regardless, it's good to see the software provide an answer
• <mattwigway> For instance, SFO to Gilroy in the morning - BART to BART
• <mattwigway> (I don't think you can go straight from Caltrain to the
• <novalis_dt> I can get a 5-transfer from Philly to Staten Island
• <novalis_dt> (on Google)
• <novalis_dt> Ooh, there's a 6.
• <mattwigway> never mind, the 168 comes to Caltrain, so that's only a
• <novalis_dt> But it's well-divided -- 3 in philly +amtrak+3 in NYC
• <novalis_dt> And Google does come up with some 3-transfer routes for the
• <novalis_dt> I'm still not 100% sure how to segment urban areas
• <FrankX> Again, I think our SW should provide an answer...so increasing
• <mattwigway> If we're building based on the list I'm working on, we
• <novalis_dt> mattwigway, what's an UZA, and do we have a shapefile or
• <mattwigway> novalis_dt, sorry, it's a census urbanized area
• <novalis_dt> FrankP, our favorite test trip is Wilsonville to Sandy,
• <mattwigway> Which is linked to an agency by the National Transportation
• <mattwigway> which I'm currently working on linking to GTFS
• <mattwigway> That's where I came up with these enormous metro areas for
• <mattwigway> And they do have associated geometries
• <FrankX> Dave, I'll add Sandy to Willsonville that to our OTP tests
• <novalis_dt> FrankP, the timing depends heavily on time-of-day
• <novalis_dt> Assuming your settings are the same as mine, 2:35 is fast
• <novalis_dt> If we added SAM to the dataset, everything would be fast
• <novalis_dt> Because it increases the frequency of transit, which is the
• <novalis_dt> Looking at the profiler, there are some microoptimizations
• <novalis_dt> Anyway, I'm still contemplating whether some form of
• <FrankX> About Sandy->Wil...would like to add SAM and other agencies to
• <novalis_dt> FrankX, that's pretty nuts that you can't just do it. But
• <novalis_dt> (Oh, and the other reason I didn't try SHARC is that it's
• <novalis_dt> FrankP, it's actually wilsonville-to-sandy that's the
• <FrankX> Yeah, not sure who's limiting that (TriMet lawyers, management,
• <mele> yeah, it's the sandy bus that's very infrequent
• <novalis_dt> The asymmetry is because infrequent transit on the back end
• <novalis_dt> Since at the front end, (a) wait time is less expensive and
• <mele> an independent dev could do it but when a govt organization uses
• <mattwigway> novalis_dt, I guess one strategy with a trip like that
• <novalis_dt> mattwigway, I tried a variant on that, actually
• <novalis_dt> That is, I tried to do an earliest-arrival search to the
• <novalis_dt> That earliest-arrival search is much faster than the normal
• <novalis_dt> Because it only has to contain one state per vertex
• <novalis_dt> Because time == weight
• <novalis_dt> (there's no tradeoff)
• <mattwigway> is that a reverse search then?
• <novalis_dt> No
• <novalis_dt> Because while this gives us the earliest arrival, it's not
• <novalis_dt> It could well be that it's a (say) 3-transfer path
• <novalis_dt> While the true best is a 0-transfer path five minutes later
• <novalis_dt> Also, for technical reasons, it must ignore max walk
• <novalis_dt> (because otherwise, there could be a faster-but-more-walk
• <novalis_dt> So, that "earliest" arrival could be unachievable
• <novalis_dt> Anyway, moving the arrival time up to the departure time
• <novalis_dt> I mean, it planned trips, but it only brought the departure
• <novalis_dt> Hm
• <novalis_dt> Right, because I had to set waitAtBeginningFactor=1, so
• <novalis_dt> (that was the 3-transfer trip)
• <novalis_dt> Maybe if I had an epsilon transfer penalty.
• <novalis_dt> Anyway, the other problem with this is that it only makes
• <novalis_dt> OK, I think I'm done nerding out unless anyone else has
• <mele> so, the redaction bot is finally live. only in Europe so far
• <novalis_dt> Ah, I hadn't realized that it wasn't live yet
• <novalis_dt> Looks like it's kind of slow, actually
• <mele> they've been tweaking the code since april
• <mele> oh it's very slow
• <mele> i think the idea is they want to make sure it's working properly
• <mele> not sure when that will be
• <novalis_dt> Yeah, that's fair
• <mele> otherwise, not much going on with us. grant, did you want to talk
• <FrankX> Mele...What does this mean for future edits of OSM? How does
• <grant_h> sure
• <grant_h> We're going to go ahead with the plan of tagging major streets
• <mele> still not quite sure. we've thoroughly cleaned up our areas, so
• <mele> any future edits will be left alone because only agreers can edit
• <grant_h> then we'll apply at deterrant weight to those streets during
• <grant_h> If anyone's interested in the details I've written up a report
• <grant_h> novalis_dt: our plan for further interaction with the disabled
• <novalis_dt> grant_h, that's once you have one area done, or the whole
• <mele> if anyone's really curious about the redaction bot code, here it
• <grant_h> to gather information such as how much further they're willing
• <grant_h> probably a test area
• <novalis_dt> OK, sounds good.
• <FrankX> grant_h, is this work is being done primarily for use in OTP
• <grant_h> We're thinking SW Portland would be a good place to start as
• <grant_h> yep
• <grant_h> FrankX: I'll send you the write-up
• <novalis_dt> mattwigway, did you want to talk about what you're working
• <mattwigway> sure.
• <mattwigway> I'm working on looking at GTFS coverage in North America,
• <mattwigway> so that we can see what areas are and aren't covered
• <mattwigway> along with ridership data and metropolitan area data
• <novalis_dt> Sounds good.
• <novalis_dt> OK, anyone have anything else?
• <FrankX> I'm going to add config stuff to app-config.xml today. Thanks
• <novalis_dt> FrankP, no problem -- glad it's useful
• <FrankX> Will have a transfer of 4 minutes, and a depart of 2 minutes
• <FrankX> (no arrive)
• <novalis_dt> OK, that should be valid
• <novalis_dt> Let me know of any failures
• <FrankX> Will do...and I can also specify maxtransfers now too?
• <FrankX> (or are maxtransfers still via url param)?
• <novalis_dt> You can specify any parameter via XML
• <novalis_dt> One or two of them have different names than the URL
• <FrankX> One last thing...are there any default values for things like
• <novalis_dt> Yes, you should override all three
• • grant_h_ (d819d311@gateway/web/freenode/ip.216.25.211.17) has joined
• <novalis_dt> OK, so let's talk next week!
• • FrankP_ (1815504e@gateway/web/freenode/ip.24.21.80.78) has joined
• • grant_h has quit (Ping timeout: 245 seconds)
• <FrankP_> novallis_dt, @DefaultValue("-1")
• • FrankX has quit (Ping timeout: 245 seconds)
• <novalis_dt> So, -1 means "get the default value from XML (or, if no
• <novalis_dt> It's kind of a hack, sorry
• • atogle has quit (Quit: Computer has gone to sleep.)
• <novalis_dt> I'm going to go chat with jcwong86 now; I'll be back in a
• <FrankP_> no problem...thanks
• • mele has quit (Quit: Page closed)
• • mele has quit (Quit: Page closed)