Weekly check in 2012.09.20

• 13:31 <novalis_dt> We do have a meeting now, but give us two minutes because we're also finishing up another meeting.
• 13:32 -!- atogle [textual@nat/openplans.org/x-yqkmuvswrfzheacb] has quit [Quit: Computer has gone to sleep.]
• 13:32 <demory> sure thing
• 13:32 -!- grant_h [d819d3bd@gateway/web/freenode/ip.216.25.211.189] has quit [Ping timeout: 245 seconds]
• 13:34 <novalis_dt> OK, let's do it!
• 13:34 <abyrd> hi
• 13:34 <abyrd> back in text mode
• 13:35 -!- grant_h [d819d3bd@gateway/web/freenode/ip.216.25.211.189] has joined #opentripplanner
• 13:35 -!- atogle [textual@nat/openplans.org/x-liakqrbkcxriohph] has joined #opentripplanner
• 13:36 -!- eshon [eshon@nat/openplans.org/x-kxzvevuzhdzwifdg] has joined #opentripplanner
• 13:36 <novalis_dt> I've been fixing misc bugs and doing a bit of RAPTOR benchmarking now that the code is in better shape. It turns out that RAPTOR is slightly slower for small regions, but I think there is probably a bit more optimization that can be done.
• 13:36 -!- jmaki [jmaki@nat/openplans.org/x-ovdsyizdbyfakfjt] has joined #opentripplanner
• 13:37 <novalis_dt> I have not yet had the chance to benchmark large regions.
• 13:37 <demory> i've been working on building the single OTP API endpoint using novalis_dt's proxy code -- have a test version up covering about a half dozen cities and it's working great so far
• 13:37 -!- brandonwillard [~bwillard@c-71-238-143-17.hsd1.mi.comcast.net] has joined #opentripplanner
• 13:37 <novalis_dt> demory, awesome
• 13:38 <demory> i'll probably wait until OTP 0.8 is ready before building it for all N America
• 13:38 <demory> i also want to improve the OSM extract process first
• 13:38 <novalis_dt> Also, I think I might submit a patch to keepright because I've noticed a weird OSM data error that I think it does not catch.
• 13:38 <mele> novalis_dt what kind of error?
• 13:38 <novalis_dt> mele, a way with the same node, twice, in a row
• 13:39 <novalis_dt> It's not in Portland, don't worry
• 13:39 <mele> oh, strange
• 13:39 <mele> not sure how that would even happen
• 13:39 <novalis_dt> I'm not either.
• 13:40 <novalis_dt> What tool do you use to do your editing?
• 13:40 <grant_h> we use JOSM
• 13:40 <mele> probably a result of some bad automatic data wrangling
• 13:41 <novalis_dt> I couldn't figure out how to fix the problem in JOSM
• 13:41 <novalis_dt> Do you know how?
• 13:41 <mele> i mean, delete the whole thing and redraw it
• 13:41 <mele> otherwise who knows
• 13:41 <mele> copy the tags over, etc
• 13:41 <novalis_dt> Yow.
• 13:41 <mele> or at least delete the node/nodes that you're having the problem with
• 13:41 <mele> that might be enough
• 13:42 <novalis_dt> Yeah, I couldn't do that because it's shared with another way, so I would have to recreate it
• 13:42 <novalis_dt> I'm surprised that there aren't automated OSM-fixing bots
• 13:42 <mele> there are a few actually
• 13:42 <mele> but mostly they're tag-fixers
• 13:43 <novalis_dt> If you can link me to one, maybe I can hack it to handle this case?
• 13:43 <mele> hmm let me see
• 13:44 <grant_h> In JOSM if you click the middle button on the mouse you can scroll through overlapping features
• 13:44 <abyrd> I'm generating test feeds to test pickup/dropoff combinations, wheelchair boarding and headsigns at the per-trip and per-stop levels, bicycle-allowing trips, banned routes and trips, and multiple boarding search return values all with one feed that (and accompanying tests)
• 13:45 <novalis_dt> Oh, OSM Inspector actually already handles that case.
• 13:45 <novalis_dt> But of course they don't fix it
• 13:45 <mele> novalis_dt http://wiki.openstreetmap.org/wiki/Bots
• 13:46 <mele> people generally don't like bots for doing geometry though
• 13:46 <novalis_dt> This is more topology than geometry
• 13:46 <mele> well anything other than tags, I mean
• 13:48 <grant_h> novalis_dt: I don't know that I'm clear on the problem. Is it that you have duplicate node both which are part of the same way and both of which are a part of other ways?
• 13:48 <grant_h> *nodes
• 13:48 <novalis_dt> Well, there's only one node
• 13:48 <novalis_dt> But it appears twice in a way
• 13:49 <novalis_dt> http://www.openstreetmap.org/browse/way/175548746
• 13:49 <novalis_dt> (look at the end of that way)
• 13:51 <demory> ok, anything else on the osm issues?
• 13:51 <demory> if not, can we talk about the 0.8 release schedule?
• 13:52 <novalis_dt> Nothing here on that.
• 13:52 <demory> ok. what else do we need/want to take care of for 0.8?
• 13:53 <demory> i hope it can include a fix to #832 (the /routers bug), and the graph management API that we discussed yesterday abyrd
• 13:53 <novalis_dt> I will work on #832
• 13:54 <abyrd> demory, yes no problem.
• 13:54 <novalis_dt> But first I want to address skywave's issue, because it seems potentially more serious
• 13:54 <demory> for the rest of you, abyrd and i discussed adding API methods to explicitly add / remove graphs in multi graph setups
• 13:54 <abyrd> I'll take care of the graph reload API.
• 13:54 <novalis_dt> (which is why I got on this OSM thing)
• 13:55 -!- FrankP [1815504e@gateway/web/freenode/ip.24.21.80.78] has joined #opentripplanner
• 13:55 <abyrd> novalis_dt, since the way we map routers to graph objects is changing I can just hit #832 as well if you like
• 13:55 <novalis_dt> abyrd, sure, if you feel like it
• 13:56 <novalis_dt> That code was kind of a mess when I started messing with it, and I think I only made things worse
• 13:56 <demory> ok, so once we've taken care of skywave's bug, #832, and the graph api, let'
• 13:56 <novalis_dt> (not my finest moment)
• 13:56 <abyrd> we agreed on functionality yesterday with demory
• 13:56 <demory> sorry -- let's plan on doing a release
• 13:57 <demory> is there anything else we want to include?
• 13:57 <abyrd> our deployed OTP will manually register graphs as they are added and there will be an auto-scan flag for the common use case
• 13:58 <abyrd> demory, just testing to make sure there aren't regressions with my recent changes (which there very well might be)
• 13:59 <abyrd> when do you want to do the release, say early next week?
• 13:59 <demory> that sounds good
• 13:59 <abyrd> I want to make sure all the departure search stuff is working right via the TripTimes objects
• 13:59 <abyrd> great
• 13:59 <demory> i need a few days to work on the osm workflow stuff anyway
• 14:00 <demory> that and the new release are the 2 things i want in place before trying a true continental OTP build
• 14:00 <abyrd> let's shoot specifically for a deployable release on Wednesday unless some grave problem is uncovered
• 14:01 <demory> ok, great
• 14:02 <demory> alright, anything else for the check-in?
• 14:03 <grant_h> I've been working on creating GTFS for some local ferries
• 14:03 <grant_h> kpw: is it you that has done this before?
• 14:04 <grant_h> I'm almost done, but am trying to decide how to deal with the stops times
• 14:04 <kpw> grant_h, yeah
• 14:04 <grant_h> it's a bit difficult because if there is no one waiting to ride the ferry it just stays put until someone shows up
• 14:05 <kpw> we have an editor (and we've used this to create a ferry schedule in nyc)
• 14:05 -!- brandonwillard [~bwillard@c-71-238-143-17.hsd1.mi.comcast.net] has quit [Ping timeout: 245 seconds]
• 14:05 <grant_h> Does the one you were working with have a fixed schedule?
• 14:06 <novalis_dt> Yeah, the NYC ferries are definitely fixed-schedule
• 14:06 <grant_h> Ok, the ones in Oregon are just shuttles traveling back and forth over a couple hundred meters of the river
• 14:07 <kpw> oh, yikes,
• 14:07 <kpw> i can't see how you'd model that in gtfs
• 14:07 <kpw> maybe just frequency based
• 14:07 <kpw> with the "average"
• 14:07 <novalis_dt> How long is the wait at max?
• 14:07 <kpw> nubmer of trip length / boats serving
• 14:08 <kpw> or, trip lenght + average wait
• 14:08 <grant_h> its hard to say the max wait because sometimes traffic gets backed up
• 14:08 -!- brandonwillard [~bwillard@c-71-238-143-17.hsd1.mi.comcast.net] has joined #opentripplanner
• 14:09 <novalis_dt> I guess what I'm wondering is: could we model it as an OSM way?
• 14:09 <novalis_dt> That's how Google sometimes models ferries IIRC
• 14:10 <novalis_dt> http://goo.gl/maps/CwrIn
• 14:10 <mele> they're in there as OSM ways already to some extent... it would be cool if OTP could read tags about hours of operation for certain times of year and approx frequency
• 14:10 <novalis_dt> OK, ticket it and I'll implement it when I get around to it.
• 14:10 <mele> http://osm.org/go/WIC0UZxsP-
• 14:11 <mele> Awesome
• 14:11 <FrankP> I don't think the Portland Aerial Tram is accurate ... they just divide up the hours of service into what they think a trip takes (2 trams, so 1-way trip length), and make it look pretty by rounding to a nice number like 0 or 5 -- http://trimet.org/schedules/w/t1208_1.htm
• 14:11 -!- githubbot [~githubbot@sh3.rs.github.com] has joined #opentripplanner
• 14:11 -githubbot:#opentripplanner- [OpenTripPlanner] abyrd pushed 7 new commits to zmqUpdateStreamer: https://github.com/openplans/OpenTripPlanner/compare/d1b6217f25c2...15bf2fe4d62d
• 14:11 -githubbot:#opentripplanner- [OpenTripPlanner/zmqUpdateStreamer] increment after store - Andrew Byrd
• 14:11 -githubbot:#opentripplanner- [OpenTripPlanner/zmqUpdateStreamer] remove qualifier - Andrew Byrd
• 14:11 -githubbot:#opentripplanner- [OpenTripPlanner/zmqUpdateStreamer] add script to generate test GTFS, as well as generated GTFS - Andrew Byrd
• 14:11 -!- githubbot [~githubbot@sh3.rs.github.com] has left #opentripplanner
• 14:11 <novalis_dt> Is hour_on and hour_off standardized?
• 14:11 <mele> We'd have to do some research about that first before writing up the ticket
• 14:11 <mele> I'm not sure
• 14:12 <mele> probably check out the ones in Europe and see how they're done too
• 14:12 <novalis_dt> OK, I'll let you do the research, and I'll do the development :)
• 14:12 <mele> Sounds like a plan!
• 14:12 <grant_h> sorry my computer keeps freezing up,
• 14:13 <grant_h> anyway, I'm getting some data about how long a trip takes, what times of the day/week there is traffic
• 14:13 <grant_h> , and what the average wait is
• 14:14 <grant_h> so should I continue working on the GTFS or is the plan to try route along the OSM data?
• 14:15 <novalis_dt> Well, if GTFS doesn't make sense for the route (due to the on-demand nature), then maybe OSM is a better bet
• 14:15 <grant_h> ok, sounds good
• 14:16 <novalis_dt> OTOH, if you want to propose an on-demand option for GTFS, I'm sure GTFS-changes would be happy to hear it
• 14:16 <grant_h> ok, i'll look inyo iy
• 14:16 <grant_h> it
• 14:18 <novalis_dt> Cool. Anyone have anything else?
• 14:19 <demory> nothing here