Weekly check in 2012.09.27 - GeoSmartCity-CIP/gsc-opentripplanner GitHub Wiki
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: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)