2013.04.11 Weekly Check in - atlregional/OpenTripPlanner GitHub Wiki
13:33 <demory> hi abyrd, grant_h, mattwigway
13:33 <mattwigway> hi!
13:33 <demory> grant_h should we wait for Frank?
13:35 <grant_h_> probably not, he's not at the office today
13:36 <demory> ah, ok
13:36 <demory> well, let's check in quickly
13:36 <demory> my update: working on various enhancements/bug fixes w/ the new UI
13:36 <mattwigway> I'm working on implementing origin and destination modes and mode switching mid-itinerary.
13:36 <demory> also getting ready for APA this weekend, where I'll be presenting on OTP
13:37 <demory> APA = American Planning Assoc national conference in Chicago
13:37 <mattwigway> oh, sorry to interrupt.
13:37 <demory> no, np
13:37 <mattwigway> I have the framework working and now I have to set up graph building with it, and write automated tests
13:38 <mattwigway> Right now I'm using it for bike parking but it can theoretically be used for any type of parking or renting
13:38 <mattwigway> The issue I'm running into is that (here at least) representing a large bike parking area as a node is not necessarily sufficient.
13:39 <mattwigway> If anyone has ideas please let me know.
13:40 <abyrd> I noticed the other day that otp.zip had reached 230MB in size. Turns out there are several JARs and WARs inside containing the full set of dependencies.
13:41 <abyrd> by putting all the dependencies into a shared directory and then pointing the servlet container at it (or putting it on the classpath when running graph builds etc.) it's possible to get the size down to about 60MB.
13:42 <abyrd> So overall I think we should avoid shaded jars and need to review our dependencies -- constant risk of bloat.
13:43 <abyrd> I have received all signatures for the SFC agreement (except one) and we have a call lined up tomorrow to finalize the agreement.
13:44 <mattwigway> one procedural question: are we moving the main repository somewhere other than openplans/opentripplanner?
13:44 <mattwigway> It's fine by me either way, just curious.
13:46 <abyrd> mattwigway, once the committee is formed we'll vote on moving it
13:47 <abyrd> but yes, we expect to transfer it to another github organization account
13:49 <mattwigway> it appears to be a user, not an organization, but github allows users to be converted to organizations
13:49 <mattwigway> (but it's not mine)
13:49 <demory> ok. maybe David T set that up
13:50 <demory> we can ask during the call tomorrow
13:51 <demory> oh, FrankP / grant_h_ -- the dates for my Portland trip are set; I'll be there Mon 5/5 - Wed 5/8
13:52 <demory> also, I should have another iteration of the TriMet demo ready to see by the weekend
13:52 <grant_h_> Sounds good, I know there's a lot of interest from other folks at TriMet about Analyst
13:53 <grant_h_> and I can tell you its a big improvement from the decision making tools that are being used now
13:53 <mattwigway> incidentally, abyrd, for the shaded jar issue, perhaps we should set up shell scripts/batch files that allow users to run the tools without needing to understand classpaths, &c.
13:53 <demory> grant_h_, yeah, I've actually been doing some work on a simple Analyst module for the new leaflet UI framework
13:54 <demory> it allows for better integration between the trip planning and analyst functions
13:54 <mattwigway> incidentally, TriMet folk, you might be interested in Busby, Jeffrey R. 2004. �Accessibility-Based Transit Planning�. Massachusetts Institute of Technology. http://hdl.handle.net/1721.1/32414.
13:54 <demory> i.e. you can swith to "analyst" view for any point in your itinerary and see the accessibility rasters, etc.
13:54 <abyrd> mattwigway, yes the otp.zip already contains some batch files. it would make a decent self-contained distribution except that it uses absolute paths
13:55 <mattwigway> It's about planning using computed accessibility measures.
13:55 <abyrd> between the large size and the requirement to unzip it into the root of the filesystem (which defies convention) I never used it
13:55 <mattwigway> Yeah, I haven't in a long time.
13:55 <abyrd> but it will be useful when it can be relocated elsewhere in the filesystem
13:55 <mattwigway> I'm going to have to jump off now, but I'll talk to y'all later.
13:56 <abyrd> I also made a pass through the wiki updating some documentation. I'm going to try to make a habit of doing that once a day.
13:56 <mattwigway> We might also think about translating the more core documentation (e.g. GettingStartedEclipse) into other languages since it's an international project.
13:57 <abyrd> mattwigway, that's a noble goal but those tutorials need to be completely rewritten first
13:57 <grant_h_> mattwigway: thanks for the link
13:58 <abyrd> the number one comment I get when I ask people about OTP is "the documentation is misleading"
13:58 <abyrd> (and "I had to buy more memory" :)
13:58 <FrankP> demory -- great ... looking forward to your visit. things on my side to address: setting up call agents tools and how to backup the fieldtrip database
14:01 <tuukkah> hey guys, any more info somewhere on the leaflet ui framework that was mentioned above?
14:02 <demory> FrankP, thanks, let me know if you want to discuss those further sometime
14:03 <demory> tuukah, the leaflet UI is still pretty experimental, and not yet well documented. I'll be working on docs in advance of that Portland trip next month
14:03 <demory> for now, all the work is in the leaflet-ui branch
14:04 <tuukkah> interesting, i should have a look
14:05 <tuukkah> we've built a prototype leaflet ui here in helsinki (in collaboration with manchester and tampere)
14:05 <FrankP> demory, feel free to send info any additional steps to get the fieldtrip module working...assuming its transactional to some extent, and that the data being captured needs to be backed up, etc... and if that's the case, I have a server that I'll dedicate to the call agents.
14:06 <abyrd> tuukkah, regarding your earlier question OTP is aware of parent stations, but does not make extensive use of them. they can be used to automatically define pathways between stations.
14:08 <tuukkah> abyrd, i see. parent stations are a gtfs concept i've never thought about before
14:09 <abyrd> they can be useful in structuring large systems, but OTP doesn't do anything too sophisticated with them yet
14:13 <tuukkah> if you want to check out our leaflet prototype, here's the helsinki version (you shouldn't let the browser geolocate though!):
14:15 <demory> tuukkah, thanks for the link! i'll take a look at it
14:16 <tuukkah> if any of you are with openplans in nyc, you may have gotten a message from my colleague who's visiting the city in a week
14:18 <tuukkah> demory, the otp part isn't in good shape yet but just the basic functionality hacked together
14:22 <demory> tuukkah, looks good! basic trip planning seems to be working for me
14:23 <demory> also, about OpenPlans, a couple of us used to work there, but not anymore
14:24 <tuukkah> i see. is that why you're going with SFC?
14:24 <demory> but there still is a good team of people there doing exciting stuff, hopefully your colleague can connect while he's there
14:25 <tuukkah> is any of you in nyc or washington dc?
14:26 <demory> yeah, re the move to SFC -- OP is beginning to focus more on open gov't advocacy and related topics so we figured SFC would be a more appropriate long term home for OTP
14:27 <demory> i don't think anyone on the chat now is in NYC or DC
14:28 <demory> though our colleage Kevin, who also works on OTP and some related projects, is in DC
14:30 <tuukkah> i see. are you guys setting up a new company for otp business or doing it via SFC?
14:33 <tuukkah> we're code for europe fellows here in helsinki this year. i'm with helsinki regional transport authority and my colleague is with city ict department
14:36 <tuukkah> demory, can you give me kevin's email addr so we can get in touch regarding them perhaps having a chance to meet in DC?
14:36 <demory> tuukkah -- three of us former OpenPlans people (myself, abyrd, and Kevin) have started a company called Conveyal which will continue to support OTP, among other work. SFC will be facilitating the community side of OTP, including managing the IP, the project steeting committee, etc.