Weekly check in 2012.09.27

• 13:36 <demory> hey, should we go ahead w/ a check-in?
• 13:36 <novalis_dt> Sure!
• 13:36 <demory> sorry i forgot to send a reminder today
• 13:36 <novalis_dt> grant_h, is frankp around?
• 13:36 <novalis_dt> On this topic, I wanted to ask him about some front-end stuff
• 13:36 -!- FrankP [d819d287@gateway/web/freenode/ip.216.25.210.135] has joined #opentripplanner
• 13:36 -!- eshon [eshon@nat/openplans.org/x-mnevwlpzgdsmvoza] has quit [Ping timeout: 245 seconds]
• 13:38 <demory> ok why don't we get started
• 13:38 <demory> i'm mainly working on improving the OSM extract -- abyrd at some point later i might want to talk to you about postgres issues
• 13:38 <abyrd> demory, sure
• 13:38 <demory> this involved a massive amount of data and i'm not sure i'm handling it best
• 13:39 <demory> otherwise, want to upgrade deployer to 0.8 today and do some testing there
• 13:39 <novalis_dt> Wait, has 0.8 been released?
• 13:39 <demory> yes!
• 13:39 <demory> late yesterday, i think
• 13:40 <abyrd> I guess the big news is that we did the 0.8 release yesterday, which includes novalis_dt's implementation of the RAPTOR algorithm, changes to the street representation, and support for real-time updates to timetables, among other things.
• 13:40 <demory> abyrd, are you planning to update the changelog on the wiki?
• 13:40 <novalis_dt> Weird, I don't see it in the branch list
• 13:40 <novalis_dt> So it probably didn't include my floating island changes?
• 13:41 <abyrd> I didn't make a branch, just a tag
• 13:41 <FrankP> I don't see it in the branch list either, but do see the stable branch has changed
• 13:41 <abyrd> since most of the outstanding work was merged in
• 13:42 <novalis_dt> Really?
• 13:42 <novalis_dt> This doesn't look right.
• 13:42 <abyrd> What doesn't look right?
• 13:42 <novalis_dt> git log stable
• 13:42 <abyrd> I released off of master. Were we planning to release off of stable?
• 13:43 <novalis_dt> no, but stable should be at least the latest released version
• 13:43 <FrankP> +1 re 'stable'
• 13:44 <FrankP> (only thing changed in stable right now are the pom.xml files)
• 13:44 <novalis_dt> Also, how do I see what's included in the 0.8 tag?
• 13:45 -!- brandonwillard [~[email protected]] has quit [Quit: Leaving.]
• 13:45 <novalis_dt> My checkin: I've checked in some fixes on misc issues and done some more failed optimization on RAPTOR. Also, abyrd, kpw, and I were just discussing snapping of endpoints and also of stops. For snapping endpoints, we want to use a fuzzy snap depending on the user's zoom level. FrankP, does it seem possible to you to send an uncertainty radius with requests?
• 13:48 <abyrd> novalis_dt, you're right there's something bizarre with the release
• 13:49 <novalis_dt> abyrd, also, I would really like to include the two patches from last night!
• 13:49 <abyrd> great, because it looks like I'm going to need to redo it.
• 13:49 <novalis_dt> Cool.
• 13:50 <grant_h> novalis_dt: w/r/t examples of snapping not working properly check out issue #625
• 13:51 <novalis_dt> grant_h, thanks
• 13:51 <grant_h> no prob
• 13:51 <novalis_dt> ah, right.
• 13:52 <grant_h> yeah we solves some of those by preferring snapping to platforms
• 13:52 <grant_h> *solved
• 13:52 -!- githubbot [~[email protected]] has joined #opentripplanner
• 13:52 -githubbot:#opentripplanner- [OpenTripPlanner] abyrd pushed 2 new commits to master: https://github.com/openplans/OpenTripPlanner/compare/979dc58f8173...1a0a519a96c2
• 13:52 -githubbot:#opentripplanner- [OpenTripPlanner/master] remove code to provide multiple departure search results - Andrew Byrd
• 13:52 -githubbot:#opentripplanner- [OpenTripPlanner/master] Merge branch 'master' of ssh://github.com/openplans/OpenTripPlanner - Andrew Byrd
• 13:52 -!- githubbot [~[email protected]] has left #opentripplanner
• 13:56 <demory> ok, anything else for the check-in?
• 13:56 <demory> abyrd, just let me know when the re-release is ready
• 13:56 <demory> i'd like to blog about it at some point
• 13:56 <abyrd> the deal is that I did the opposite of what I intended and released off of stable instead of master
• 13:56 <novalis_dt> I'm still thinking about the snapping thing
• 13:57 <novalis_dt> But other than my question for FrankP, I'm not sure I need anyone other than abyrd and kpw for it
• 13:57 <abyrd> so 0.8.1 would either be a massive fast forward or I "rewrite history" as they say.
• 13:58 <novalis_dt> I don't object to rewriting in cases like this
• 13:58 <abyrd> or we just jump to 0.9, since it's not too insane to have a 0.8 tag on what we were calling stable
• 13:58 <FrankP> Uncertain I could send any radius, and certainly not one I'm uncertain about :-)
• 13:59 <novalis_dt> I don't really have a strong preference, so whatever you want, abyrd
• 13:59 <novalis_dt> FrankP, I mean, basically, some function of zoom-level.
• 13:59 <novalis_dt> Or is that not gettable?
• 14:00 <FrankP> It is ... I could send the resolution number (scale factor) down, possibly; with that, you could know how far out the map is. But honestly, the problem I've seen is not one of scale...it's more finding the stop on the proper street at an intersection / or when a stop is separated by some other area, and stuff gets snapped to the wrong street.
• 14:01 <abyrd> anyway, my checkin: I have been working on optimizing Analyst tile rendering so it doesn't take absurd amounts of resources. Initial calculations are now much faster and I'm working on a compression scheme for the tile templates.
• 14:02 <kpw> abyrd, et a, i've been wanting to suggest that we push a 1.0 release anyway
• 14:02 <kpw> given that trimet moved to production
• 14:02 <abyrd> Also sifting through my first round of AWS calibration and cleaning up/automating further runs so we have ongoing feedback.
• 14:03 <abyrd> kpw, then releasing a 0.9 makes "almost 1.0".
• 14:03 <novalis_dt> FrankP, there are two issues: there's stop snapping, and endpoint snapping.
• 14:03 <novalis_dt> FrankP, for endpoint snapping, Portland doesn't really have problems, because it has a well-connected network
• 14:04 <novalis_dt> But there are places in i.e. San Francisco where the nearest endpoint to the click is in a pedestrian overpass connected to a park or some such nonsense
• 14:04 <novalis_dt> But if the zoom level is way out, we would like to link the endpoint to all nearby edges
• 14:04 <novalis_dt> For stop snapping, the problem is more complex and we are still contemplating it
• 14:05 <novalis_dt> But if you have cases that are still in error for stop snapping, we would love to see them, of course
• 14:05 <novalis_dt> Also, if there are cases where it would be bad to over-connect a stop (that is, to connect it to somewhere nearby that's not actually accessible), those would be useful too
• 14:05 <abyrd> I merged the zmqUpdateStreamer into master, and there were very few differences in trip planning results. However, between stable and master (both pre and post merge) there were a lot of differences. Considering the amount of changes that went into master this is not necessarily incorrect, but I think we should make sure before releasing a 1.0.
• 14:05 <abyrd> kpw, did you have a date in mind for that 1.0 release?
• 14:06 <kpw> let's do it along with the ios roll-out
• 14:06 <kpw> let's come up with a list of things we'd like to address
• 14:06 <demory> i might suggest we include the leaflet ui as part of 1.0
• 14:06 <kpw> yes!
• 14:06 <kpw> 1) leaflet
• 14:06 <demory> but there's still some work left on that
• 14:07 <kpw> 2) snapping
• 14:07 <demory> esp. for transit routing
• 14:07 <abyrd> any objections to 0.8 being what we were calling stable and 0.9 being the new release? I am a bit wary of trying to convince maven plugins to rewrite git history.
• 14:07 <demory> i like the idea of this one being 0.9, i.e. the last major pre-1.0 release
• 14:08 <kpw> great!
• 14:08 <abyrd> and another thing: is the stable branch of any use or just confusing?
• 14:08 <FrankP> stable branch very useful
• 14:09 <abyrd> ok FrankP thanks for that input.
• 14:09 <FrankP> but stable should be updated to the current release (and with maybe a cherrypick or two)
• 14:09 <abyrd> then I will fast-forward it to 0.8 and we'll be conservative about cherry-picking into it between releases.
• 14:10 <abyrd> however FrankP I'm not sure I'd throw 0.9 into production right away considering the amount of changes
• 14:10 <FrankP> Thanks Andrew. Yeah, stable is what the demo and trimet release is built off of now. It's nice having a generic name for the latest code
• 14:11 -!- eshon [eshon@nat/openplans.org/x-eafayddqypnkblek] has joined #opentripplanner
• 14:12 <abyrd> FrankP, do you still do your usual trip testing on releases before you use them in production?
• 14:14 <FrankP> Yes, we have a suite of about 100 trip plans that need to pass for any Graph build (new OSM and/or GTFS)...and if it's a new release, Grant, Mele and I will do a full-on monkey test of the code.
• 14:15 <FrankP> The tests give us a level of confidence that things are okay...if worse comes to worse, we could back out of a release w/in an hour.
• 14:15 <abyrd> FrankP, perfect. Thanks a lot for all that manual testing.
• 14:17 <grant_h> I've got one more thing, I'm working on a proposal for GTFS-changes so that GTFS can handle on demand services
• 14:17 <abyrd> We're moving toward having parallel automated confirmation, but with this release there are a lot of differences. I've got lots of raw data but need to work out tools to sift through it and spot patterns.
• 14:18 <grant_h> This is so we can include some of the ferry services in Oregon that are just shuttles back and forth across the width of the river
• 14:19 <novalis_dt> grant_h, awesome.
• 14:19 -!- eshon [eshon@nat/openplans.org/x-eafayddqypnkblek] has quit [Ping timeout: 245 seconds]
• 14:20 <grant_h> I decided to go this route instead of working off the ferry data in OSM because its difficult to include information for things like closure dates in OSM
• 14:20 -!- brandonwillard [~[email protected]] has joined #opentripplanner
• 14:20 <grant_h> for instance most of the ferries are closed on Thanksgiving day which falls on a different day each year
• 14:20 <grant_h> that makes for a messy tag in OSM
• 14:21 <novalis_dt> The iCal people handled this
• 14:21 <novalis_dt> But I think their spec is like 200 pages
• 14:21 <novalis_dt> (not all related to recurrences, but it was a giant hassle)