Weekly check in 2011.07.28

• 13:32 <demory> hello all
• 13:32 <novalis_> hi demory
• 13:33 <demory> shall we get started?
• 13:33 <FrankP> hi David
• 13:33 <novalis_> Sure!
• 13:33 <demory> ok
• 13:33 <demory> anyone else there?
• 13:34 <demory> i guess it's just us for now
• 13:34 <demory> maybe we can start with quick check-ins
• 13:34 <demory> i'll start
• 13:34 <demory> i've mostly been working on admin / non-technical stuff
• 13:34 <demory> the website, roadmap, etc.
• 13:35 <demory> but i'm beginning to work on the Euro Challenge demo
• 13:35 <demory> pulling the base data out of OSM as we speak
• 13:36 <demory> so hopefully we'll know if that's going to be feasible within a couple days
• 13:36 <novalis_> demory, you might want to talk to FrankP about that, since I think he has a better process for that
• 13:36 <novalis_> (the base layer)
• 13:36 <novalis_> I've been working on miscellaneous routing bugs and suboptimalities.
• 13:37 <demory> ok let's come back to that later
• 13:37 <novalis_> In particular, I've been working with the TriMet interns on issues around narratives and bike routing
• 13:37 <novalis_> I've also been chatting with Andrew about the dread #409
• 13:37 <novalis_> He has been having some git/maven/eclipse issues
• 13:37 <novalis_> Has anyone else had issues with eclipse and/or maven since the move to git?
• 13:38 <FrankP> only 1 day back from vacation since the workshop -- this week is moving current map & otp over to new production servers. Need to get git repo of OTP in place of existing .svn stuff (e.g., cron to pull latest code, and rebuild code and graph).
• 13:38 <demory> honestly I haven't really been working with the code much
• 13:38 <demory> but i'll let you know if i run into anything
• 13:40 <demory> ok thanks for the updates
• 13:40 <demory> can we talk about the base layer for the Pacific NW demo?
• 13:40 <FrankP> as to building a map base layer from OSM, I'm not doing that...I still use the Portland Metro data.
• 13:40 <demory> my plan was to define a polygon that is a buffer of all the routes we're looking
• 13:41 <demory> and then use osmosis to extract from planet.osm
• 13:41 <novalis_> FrankP, But you're using OSM for routing, right?
• 13:42 <FrankP> yup. big bounding box pull directly from their server nightly (bbox includes Clark County in WA, and down south past Salem ... way beyond our bus routes).
• 13:42 <FrankP> not planet.osm...directly from a rest server...I'll get the URL.
• 13:43 <demory> ok
• 13:43 <demory> yeah if I can avoid working with planet.osm that would be nice
• 13:43 <FrankP> http://jxapi.openstreetmap.org/xapi/api/0.6/map?bbox=-123.4,44.8,-121.5,45.8
• 13:43 <demory> it's a 17GB download
• 13:43 <demory> ok thanks
• 13:44 <novalis_> Wait, I thought there were limits on the API servers?
• 13:44 <FrankP> yeah, that stuff is kind of a mess. jxapi allows pretty big bboxes to be pulled down.
• 13:44 <demory> is there?
• 13:44 <novalis_> I guess jxapi is better
• 13:44 <demory> well, i'll try it for the OR/WA/BC area, and see what happens
• 13:45 <FrankP> I don't think so, as long as you're not doing this all that often. I have the contact for the owner...
• 13:45 <FrankP> nightly is ok for that bbox (could probably be more often)
• 13:46 <kpw> one other route to explore:
• 13:46 <kpw> i've been downlloading the state pbm files and merging them together
• 13:46 <kpw> e.g. for DC metro i pulled in VA, MD and Dc
• 13:46 <kpw> combined and then extracted the metro area
• 13:46 <demory> ok. what tool do you use to merge?
• 13:46 <kpw> osmosis
• 13:47 <kpw> it will combine the pbm files and do the extraction
• 13:47 <kpw> (at least using bbox, not sure about buffers)
• 13:47 <FrankP> jxapi technical contact: Ian Dees [[email protected]]
• 13:48 <demory> i believe it does polygon based extracts too
• 13:48 <demory> (of course i haven't actually tried it until now)
• 13:48 <FrankP> jxapi upper limit of bbox size is 10 square degrees
• 13:49 <demory> kpw where do you download the state PBMs? does it have BC too?
• 13:49 <kpw> http://www.geofabrik.de/data/download.html
• 13:49 <kpw> they do weekly dumps as pbm and xml
• 13:50 <kpw> might be other similar sources too but this has worked for my purposes
• 13:50 <novalis_> We really ought to have something on the wiki about this
• 13:50 <demory> 10 sq deg may be too small, i'll have to look into that. but it sounds like merging the state files could work too
• 13:51 <demory> in any case i still want to extract the buffered area at the end. i want to keep this graph as small as possible
• 13:51 <novalis_> Speaking of which, I think there is some other wiki cleanup that could be done -- in particular, adjusting the checkout instructions to no longer mention subversion. Does someone want to take the lead on that?
• 13:51 <demory> i can do that
• 13:52 <demory> i've been doing some cleanup on the wiki but there is much more to do
• 13:52 <demory> a lot of the formatting -- spacing, etc. -- needs to be tweaked
• 13:52 <FrankP> and the front-page image is too big :-0
• 13:52 <novalis_> I actually thought of a way to make the graph a tiny bit smaller, if you end up just a bit too tight: simply replace every instance of CAR in the DefaultWayPropertySet with NONE.
• 13:53 <novalis_> Yeah, the spacing got a little wacky during the import
• 13:53 <demory> and some of the stuff is out of date (old roadmaps, etc)
• 13:54 <demory> i will fix the image too :)
• 13:54 <kpw> i think the pdm merge/extract step could also be built into the graph builder (maybe).
• 13:54 <novalis_> Yeah, Trac was shrinking that image down to 400px wide, but github didn't have that feature.
• 13:55 <novalis_> kpw, there was a ticket on that, but we ran into some trouble getting the protocol buffers stuff mavenized. Since then, the situation seems to have improved, so maybe it's worth reexamining that ticket
• 13:55 <kpw> at the very least, i'll document my steps for the dc demo to explain how to do it manually
• 13:55 <kpw> cool
• 13:55 <novalis_> I would feel very good about having that old ticket finally killed.
• 13:56 <FrankP> did someone say, "protocol buffers"?
• 13:56 <kpw> yes re OSM
• 13:56 <demory> i agree but i still want to do this manually w/ the PNW demo. i need practice w/ this stuff
• 13:56 <kpw> the PBM files are proto buffs
• 13:56 <kpw> yeah, it's not too tricky (at least with the bbox extract) and is worth trying out
• 13:58 <demory> ok well i have some things to try with that. anything else on the Euro Challege?
• 13:58 <demory> did people see the latest edits to the letter by Wojciech?
• 13:58 <demory> i think it looks good so far
• 13:59 * novalis_ looks
• 14:00 <demory> well we have some time on that. i'm more concerned about the demo right now
• 14:00 <demory> i'll keep you all posted on how that goes
• 14:00 <novalis_> Sure. We should also think about figuring out how we are going to manage configurations and builds on demos.
• 14:00 -!- vdeparday [~[email protected]] has joined #opentripplanner
• 14:01 <demory> yeah
• 14:01 <demory> i haven't really thought about how deployment would work, just trying to get something on my local machine first
• 14:02 <demory> what do we do for the nyc one that's online now?
• 14:02 <novalis_> We don't.
• 14:02 <demory> ah
• 14:02 <novalis_> At some point, Nick BS or Rob built it, and it's been untouched ever since
• 14:02 <demory> so it's running pretty old code then
• 14:03 <novalis_> Yep.
• 14:04 <FrankP> BTW, are we going to continue to use Trac for tickets?
• 14:04 <novalis_> FrankP, I was talking with Andrew about this, and I think we should probably switch to Git
• 14:05 <novalis_> the downside is that our ticket history is munged -- it looks like everything is by me
• 14:05 <novalis_> It does have, on the end of each comment a little tag: --fpurcell, or --bdferris or whatever
• 14:05 <novalis_> But that's hard to notice
• 14:05 <FrankP> you the man.
• 14:05 <novalis_> But the advantages are: (a) we keep our ticket numbers, and (b) we can turn off trac.
• 14:06 <FrankP> fair trade-off
• 14:06 <novalis_> OK, then I'm going to turn tickets back on in git.
• 14:06 <demory> so are all the tickets still on Trac? or have we started creating new ones on Github?
• 14:07 <novalis_> I imported the tickets -- take a look.
• 14:07 <novalis_> https://github.com/openplans/OpenTripPlanner/issues
• 14:07 <novalis_> Actually, I created one on trac after the import, so I have to migrate that one
• 14:08 <demory> ok
• 14:08 <demory> so going forward new ones should be created on git?
• 14:09 <novalis_> Sure.
• 14:09 -!- andrewbyrd [~[email protected]] has joined #opentripplanner
• 14:09 <FrankP> git issues looks good...not a problem that you're attached to each (and thankfully git sorts in reverse...saves me 3 clicks)
• 14:10 <andrewbyrd> Hi everyone, sorry I'm late.
• 14:10 <novalis_> hi andrewbyrd
• 14:10 <FrankP> hey andrew
• 14:11 <demory> hey
• 14:11 <novalis_> scrollback = http://pastie.org/2285754
• 14:11 <demory> we were just talking about tickets. they're now visible on GitHub if you havent seen them yet
• 14:12 <andrewbyrd> novalis_: thanks, I was about to ask for that
• 14:12 <novalis_> yeah, Andrew and I had spoken about the issue situation
• 14:12 <novalis_> So, now how do we turn off issues in trac?
• 14:12 <novalis_> Also we should remove some of the really old ones that aren't relevant to the modern world.
• 14:13 <novalis_> ie #8
• 14:13 <demory> so we're completely done with them in trac? all of the discussions, etc. have been imported?
• 14:13 <novalis_> Looks like it!
• 14:14 <andrewbyrd> I moved some of the longer tickets over to wiki pages
• 14:14 <demory> ok great
• 14:14 <andrewbyrd> there are a probably a few more that could potentially be in that format, but most of the current debates that didn't belong in tickets are in wiki pages
• 14:16 <demory> yeah i see a few that have 10+ comments. novalis_ now i see what you mean about you owning all of them
• 14:17 -!- kpw [46157fcc@gateway/web/freenode/ip.70.21.127.204] has quit [Ping timeout: 252 seconds]
• 14:17 <andrewbyrd> I was thinking the import would be more tolerable if it was not david but some generic user who created all the tickets, so it didn't give the impression of one user posting everything
• 14:18 <andrewbyrd> but once the issues are created, there is no means to remove them through the API
• 14:19 <novalis_> I can live with being a bit too loquacious
• 14:21 <demory> yeah i think we can work around that. going forward others will start creating their own and it will look more like a multi-person effort
• 14:21 <novalis_> And hopefully, we'll close some of those old tickets!
• 14:21 <demory> also the tickets can still be assigned to anyone regardless of who owns them right?
• 14:22 <novalis_> Right.
• 14:22 <demory> yeah i will start going through them looking for candidates for closure. (yes #8 definitely qualifies)
• 14:22 <andrewbyrd> yes, I think the only disadvantage is that you have to check the bottom of the comments to see who wrote them
• 14:22 <novalis_> Actually, FrankP, I don't see you on the OTP team on github -- can you make an account?
• 14:23 <novalis_> Also, there seems to be a bit of a problem with the import where some closed tickets didn't really get closed.
• 14:23 <demory> hmm
• 14:23 <novalis_> but that's fixable
• 14:23 <demory> i guess we should keep trac online a little bit longer
• 14:24 <demory> so I can cross-reference between it and github
• 14:24 <novalis_> Sure.
• 14:26 <demory> that reminds me, i've been talking to Evan about the new website. i think he's going to create a dev instance of wordpress for me to work with
• 14:26 <novalis_> ok, cool.
• 14:26 <demory> so nothing will change at otp.org right away
• 14:27 <demory> and even when we do launch the new site, we might be able to keep trac running in the background if needed
• 14:27 <demory> but it sounds like we may not have to
• 14:27 <FrankP> novalis_, I'm on github and 'watching' OTP...don't see a OTP team list nor how to join
• 14:28 <novalis_> Ok, maybe I need to add you or something
• 14:28 <FrankP> account is fpurcell
• 14:28 <novalis_> demory, yeah, the tickets are the last thing we care about trac for
• 14:28 <novalis_> Oh, I just hadn't added you. Sorry about that!
• 14:29 -!- vdeparday [~[email protected]] has quit [Remote host closed the connection]
• 14:29 <novalis_> I just assigned you an issue -- does that show up for you somewhere?
• 14:30 <novalis_> Also, what else is on the agenda for today's meeting?
• 14:31 <demory> i really don't have anything else
• 14:31 <andrewbyrd> Going back to the maven/git issues you mentioned earlier
• 14:32 <novalis_> Yeah...
• 14:32 <andrewbyrd> I have run into quite a bit of flakiness in different forms
• 14:32 <novalis_> In my email, I actually forgot to mention that I always run mvn test from the command line, although I run individual tests from Eclipse's JUnit runner
• 14:32 <andrewbyrd> I get the impression they overhauled a few things in the new Elcipse release, possibly to fix some of this, but adapting to that version is going to involve redoing some details of the POM
• 14:33 <novalis_> That doesn't bother me in principle -- only in practice, I am not great at Maven
• 14:33 <novalis_> Do you think bdferris would be able to do it?
• 14:34 <andrewbyrd> I've got it mostly working, the remaining problem is that when I do a build from the command line everything is fine, but nothing happens from inside eclipse
• 14:34 <andrewbyrd> not nothing, there is acivity on the maven console, but it is not a full build
• 14:34 <novalis_> When you look at that activity, does it tell you what's wrong?
• 14:35 <andrewbyrd> No errors.
• 14:35 <andrewbyrd> I believe it's simply not building the submodules
• 14:36 <novalis_> I had so many problems with Helios that I'm reluctant to try Indigo
• 14:37 <andrewbyrd> Anyway, apparently there's not much to compare with, and I suppose I need to figure this out on my own
• 14:37 <novalis_> But I guess it won't hurt to download it just for testing...
• 14:37 <andrewbyrd> The problem is it's getting in the way of me testing my changes
• 14:37 <novalis_> Can you test manually on Tomcat?
• 14:38 <andrewbyrd> But I'm not even on Indigo. I tried that once, and switched back immediately once I realized I was going to need to rewrite the poms
• 14:38 <andrewbyrd> So I'm on Galileo
• 14:38 <novalis_> Oh!
• 14:38 <novalis_> So the only change is the change to git?
• 14:38 <andrewbyrd> Using the ubuntu package that used to work find
• 14:38 <andrewbyrd> Using the ubuntu package that used to work findfine
• 14:38 <novalis_> But that doesn't make any sense -- it's the same source code...
• 14:39 <novalis_> Did you try creating a new workspace and importing the projects (as maven projects) into that workspace?
• 14:40 <andrewbyrd> I think I tried every possible combination of importing maven, git and basic projects, adding git control or maven dep management after the fact, with and without the submodules as top-level projects... usually doing the git clone on the command line but also from the git repo view...
• 14:40 <novalis_> Hm!
• 14:41 <novalis_> Ok, did you try all that with the second-to-latest SVN version to prove that it's the switch to git that's the problem?
• 14:41 <andrewbyrd> Anyway, I don't expect you guys to come up with a solution at this second, since you haven't been running into this. I wonder if there are remnants of my Indigo install.
• 14:41 <novalis_> Oh, that could be.
• 14:42 <andrewbyrd> Except that it was a download from the eclipse site, in its own little directory (not a package), but that doesn't mean it didn't decide to leave who knows what elsewhere...
• 14:42 <andrewbyrd> Still, it's doing this to me on two different machines
• 14:43 <andrewbyrd> You're right, clearlythe thing to do is to try again on svn and see if it works correctly
• 14:44 <andrewbyrd> And yes, I will just do the maven and deployment stuff on the command line for the time being
• 14:44 <andrewbyrd> I don't really think this is a problem directly related to git, it's a quirk somewhere that just needs to be identified and avoided.
• 14:45 <novalis_> Right.
• 14:45 <andrewbyrd> One other thing: the docs on defaultWayPropertySetSource
• 14:46 <novalis_> Are they not correct?
• 14:48 <andrewbyrd> I think they are fine, but there are xml samples on the wiki page that still include defaultAccessPermissionsSource
• 14:49 <novalis_> Oops!
• 14:49 <novalis_> Will fix
• 14:49 <andrewbyrd> Now that I do a search, it's a small change, I should have just fixed it instead of complaining
• 14:50 <novalis_> I already have the wiki checked out.
• 14:50 <andrewbyrd> but I just remembered noticing that
• 14:50 <novalis_> Looks like just one, right?
• 14:51 <novalis_> (and I just fixed that one)
• 14:52 <novalis_> I love that github wikis are in git so I can just go in with Emacs and fix stuff
• 14:52 <andrewbyrd> the "Permissions and bicycle safety" mentions defaultAccessPermission
• 14:52 <novalis_> Oh, one more thing that didn't get imported to github issues from trac: milestones
• 14:53 <novalis_> andrewbyrd, I don't see that.
• 14:54 <andrewbyrd> Would it make more sense to redo the milestones, rethinking them in our current context rather than importing them?
• 14:55 <andrewbyrd> novalis_: yeah, it's no longer there. looks good.
• 14:56 <FrankP> novalis_, issues view lists the one issue assigned to me....that said, I'm unable to fix this particular issue re right-click, so can you assign it to someone else and/or close it.
• 14:56 <novalis_> Unable because you don't have time, or because it's too technically difficult, or because it's a bad idea?
• 14:57 <FrankP> all three
• 14:58 <novalis_> Can you make a comment to that effect and then close it?
• 14:58 <FrankP> sure.
• 14:58 <novalis_> Thanks.
• 14:59 <demory> re milestones, I can take a look at that. per Andrew's suggestion, this could be a good chance to reassess that
• 14:59 <andrewbyrd> I should mention that the conversations copied over from tickets are at https://github.com/openplans/OpenTripPlanner/wiki/ComplexIssues
• 14:59 <novalis_> Cool.
• 15:00 <demory> so anything else while we're all here?
• 15:00 <andrewbyrd> There are no links into this page yet because I wanted to clean it up a bit, but if we are now using github issues I'll link it in.
• 15:01 <demory> sounds good, thanks
• 15:01 <novalis_> I have created two milestones: TriMet demo, and Future. Do we need more milestones than that?
• 15:02 <demory> that's fine for now. Trimet demo is obviously the immediate focus
• 15:02 <andrewbyrd> demory: I guess our plan from last week about copying tickets manually is no longer relevant, so you no longer need me to give you a list of the tickets that were wikified
• 15:02 <demory> right
• 15:03 <novalis_> We should make sure they are closed in the github tracker
• 15:03 <andrewbyrd> Agreed, I think that's enough milestones for now
• 15:03 <andrewbyrd> right, I closed them as I was going along in trac but you imported to github before that
• 15:03 <demory> once we have a clearer picture of future plans re analytical tools, system mapping, etc. we may want to break the future one up into mutiple
• 15:03 <andrewbyrd> I'll take care of closing them, I have a list
• 15:04 <novalis_> demory, that's reasonable.
• 15:04 <demory> but that will come later
• 15:05 <novalis_> Maybe we need one more milestone for "on fire"
• 15:05 <novalis_> i.e. #409
• 15:06 <andrewbyrd> That also sounds reasonable
• 15:06 <demory> do github issues have a priority/urgency field like on svn?
• 15:06 <andrewbyrd> for 409 itself, the code changes are very simple, but I got mired in this maven build mess
• 15:06 <novalis_> I don't see that...
• 15:08 <demory> there does seem to be a concept of issue "labels" -- so we could track especially urgent ones that way too
• 15:08 <demory> i.e. perhaps "on fire" should be a label not a milestone?
• 15:09 <novalis_> I actually think the key questions an issue tracker answers are, "what should I work on next?", and "when will this bug be addressed?"
• 15:09 <andrewbyrd> I see that there is now an on fire milestone :)
• 15:09 <novalis_> So having the order of work be "on fire", "trimet demo", "future" makes a lot of sense to me
• 15:10 <novalis_> For labels, we should probably restore the old "which component is this in" labels
• 15:10 <andrewbyrd> to me labels are more for specifying which components are concerned, so people can spot things they understand best
• 15:10 <demory> ok that sounds reasonable
• 15:10 <FrankP> trimet beta (instead of demo
• 15:10 <novalis_> Fixed
• 15:13 <andrewbyrd> So, just to confirm: we are doing everything on github now. trac is purely for reference?
• 15:13 <demory> that is my understanding, yes
• 15:13 <novalis_> Yep.
• 15:13 <demory> also i can work on assigning labels to components as i go though the tickets looking for ones to close
• 15:15 <novalis_> Cool!
• 15:15 <FrankP> One last one, demory. Anyone hear from Google about GTRTFS? (Bibi said a few weeks back we're waiting on Google to make their spec public) My #1 ticket is https://github.com/openplans/OpenTripPlanner/issues/412, and I hope we can get that into the TriMet beta.
• 15:17 <novalis_> demory, I can't remember if you are familiar with the issue -- if not, I can fill you in.
• 15:17 <demory> I have not heard anything from Google. But I'll look into to it
• 15:18 <demory> i remember it being discussed at the conference but haven't heard anything since
• 15:18 <novalis_> Thanks.
• 15:18 <demory> let me check w/ Kevin, perhaps he has more recent info
• 15:19 <demory> but i have assigned the ticket to the Trimet beta
• 15:21 <demory> ok, i say we call the official check-in over. i will post transcript to wiki
• 15:21 <novalis_> Cool.
• 15:22 <andrewbyrd> ok thanks
• 15:22 <demory> i should be on irc for a while longer though
• 15:22 <demory> thanks everyone!