Weekly check in 2013.03.14

• 13:35 <demory> hey FrankX, grant_h, should we do a quick OTP check in?
• 13:36 <demory> not sure if abyrd is going to join us
• 13:36 <FrankX> Hey David...yes, please
• 13:36 <demory> ok
• 13:36 <demory> i have a few front-end additions I'm about to check in, including geocoding support for the Calltaker and Fieldtrip modules
• 13:36 -!- mjumbewu [~[email protected]] has joined #opentripplanner
• 13:37 <FrankX> Interesting thing on my end this week was DST on Sunday. Current TriMet trip planner planned things 1 hour ahead...that bug appears fixed in HEAD though
• 13:37 <demory> thanks for making the test geocoder instance avialable, it's working great
• 13:37 <FrankX> Cool. Very simple fix on my end...thanks Matt.
• 13:37 <demory> hmm, that's odd
• 13:38 <FrankX> Yeah, this has been a bug that's hit us in years past too (even last November) ... but our OTP instance is from September. DT fixed it after November, I'm thinking.
• 13:39 <demory> ah, ok
• 13:39 <FrankX> No one complained, so not a big deal. And we have till next November to get a new version in place...
• 13:40 <demory> so, i should have the demo updated w/ the lastest UI updates later today or tomorrow
• 13:41 <demory> we're migrating that to a new AWS setup (previously it was managed by OpenPlans) which is the reason for the hold up there
• 13:43 <demory> i don't know the latest status of abyrd's work on the routing info. grant_h, are you still willing to ticket the various problem trips you had found?
• 13:44 <FrankX> BTW, on the geocoder front. I'll continue to support the current maps/geocode stuff. But you might also want to try using SOLR, and it's progressive search (google suggest) functionality -- http://maps5.trimet.org/solr/select?start=0&limit=10&wt=json&qt=dismax&rows=10&q=834%20SE
• 13:45 <FrankX> This code in OTP Ext UI used the SOLR interface: https://github.com/openplans/OpenTripPlanner/blob/master/opentripplanner-webapp/src/main/webapp/js/otp/core/SolrComboBox.js
• 13:46 <grant_h> demory: sure, I have a couple of pressing projects right now, but I should have time to do so next week
• 13:47 <demory> FrankX, thanks, I'll look into that -- I'm using the JQuery UI autocomplete widget which should work well with that
• 13:48 <demory> grant_h, great, thanks
• 13:49 <demory> i'll let abyrd know you plan to do that
• 13:49 <FrankX> I'm going to switch the from/to forms to use SolrComboBox.js sometime soon on the map. Currently it's used on maps.trimet.org?tool=search search box.
• 13:51 <demory> FrankX, are there any advantages to the old maps/geocode service over the solr one? i.e. more points of interest, etc?
• 13:53 <FrankX> Currently, it's the same (proprietary) geocoder as the text trip planner. I wanted to keep those the same initially, so that we could compare trips from OTP vs. Proprietary system, and so customers could go back and forth with same geocoding expectation.
• 13:53 <FrankX> I think SOLR is better though because of autocomplete paradigm
• 13:54 <demory> ok, thanks. i'll do some experimenting w/ the SOLR one later
• 13:55 <FrankX> But SOLR needs work to make matching better ... and there are some instances where data needs better handling (e.g., snap to street vs. centroid of taxlot, which can break for non-square taxlots on a grid)
• 13:56 <FrankX> Also, proprietary geocoder uses address interpolation, whereas SOLR uses a master address file (and no interpolation) ... that's a big question mark when used in text trip planner, w/out progressive search -- hoping it won't be a show stopper for folks (shouldn't be, but...)
• 13:57 <FrankX> BTW, our current proprietary geocoder is the source of 75% of complaints on that old trip planner....it's gotten better over the years, but still a major headache for folks used to more robust geocoders from google, etc...
• 13:58 <demory> right
• 14:00 <demory> you know, at least for testing purposes, i could throw in a basic radio button widget for selecting between the two geocoders -- could be handy for comparing results
• 14:01 <demory> ok, that's all i have for right now -- i'll email you both once the demo is updated
• 14:01 <demory> anything else on your end?
• 14:03 <FrankX> I'll let grant_h make that decision...I'd say no to the radio button, as either is okay for testing. Plus, I'm not sure that the proprietary geocoder is a good system for progressive search, so I'd just go with SOLR if that's the case.
• 14:08 <grant_h> The radio button sounds convenient, FrankX you think there's not much to be learned in comparing SOLR to the results from the proprietary geocoder?
• 14:10 <grant_h> demory: before you take off, I'm going to be spending some setting up an instance of OTP analyst next week, is there documentation out there as to how to do so?
• 14:12 <demory> grant_h, regarding analyst, deploying it should be the same as deploying a regular OTP instance, except that you also deploy the opentripplanner-analyst-client webapp
• 14:13 <demory> abyrd integrated all the anaylst functionality into the core API awhile back
• 14:13 <grant_h> ok, great
• 14:15 <demory> sure. let me know if you run into any issues w/ it
• 14:16 <FrankX> grant_h, I think geocoding compare is probably better done some other way. I'd go with SOLR, and if there are problems, send them to me...or if too many problems that gets in the way of testing, switch back to proprietary geocoder.
• 14:16 <grant_h> ok, sounds good
• 14:39 -!- abyrd [[email protected]] has joined #opentripplanner
• 14:50 -!- asutula [asutula@nat/openplans.org/x-kmekflaxjuevzgfh] has quit [Quit: Computer has gone to sleep.]
• 14:50 -!- asutula [asutula@nat/openplans.org/x-ofctiifhlvfoljfz] has joined #opentripplanner
• 14:59 <demory> hi abyrd, here is the chat transcript: http://pastebin.com/0LcdJYdZ
• 15:00 <abyrd> yeah, DST error
• 15:00 <abyrd> thanks for the link
• 15:00 <demory> yeah, sorry for not sending an email reminder
• 15:00 <demory> note that grant_h offered to ticket the specific problem trips they've documented, probably early next week
• 15:02 <FrankX> abyrd, demory ... Andrew, you mentioned a few months ago a desire to refactor Spring and mvn ... any further thoughts there?
• 15:03 <abyrd> no problem about the reminder, I expect my calendar to take care of that but it looks like I have not yet mastered that feature
• 15:04 <abyrd> FrankX, yeah I have mentioned it to a few other people and it seems like a popular idea
• 15:04 <abyrd> Laurent responded to this point on the mailing list, so there's actually a conversation happening on the Spring front
• 15:05 <abyrd> feel free to chime in on maven. I think we should have a public discussion to make sure there's a chance for dissent before we rip things apart.
• 15:05 <abyrd> The thing about the maven multi-module build is that it A) works better in maven 3 and B) is unavoidable in mvn anyway because we need to produce both WAR and JAR artifacts
• 15:07 <FrankX> Sounds good. A kinder, gentler OTP code base would be welcome here too. Neither Spring nor Maven are things I'm a big proponent for...I'm a fan of Ant myself, but I don't like the proprietary build environment that results (e.g., the convention over customization idea of mvn is a good one ... but very frustrating a lot of the time in practice -- that said, I think our build is fine now that it's up & running)
• 15:09 <abyrd> if we stick with maven (convenient for the dependency management) maybe the solution is simply eliminating all the custom stuff
• 15:09 <abyrd> so it is all convention, and less room for error
• 15:10 <abyrd> the big notable example is the built in "integration test" which often conflicts with other running servers or runs out of memory causing the build to hang
• 15:11 <abyrd> and judging from messages on the list a lot of people are attempting to use the maven build as an OTP server : /
• 15:12 <abyrd> we should do a full review of all the dependencies and see if we can pare it down as well
• 15:15 -!- mjumbewu [~[email protected]] has quit [Ping timeout: 258 seconds]
• 15:22 <FrankX> My $0.02 on the build ... I just need a command line that builds the 3 war files and graph-builder.jar executable. I currently use the integration project, since that's the only cmd line I know of to build the entire project in one fell swoop. I also have to remember to edit the memory parameter and some other stuff in opentripplanner-integration/pom.xml anytime that file changes (like for new releases, etc...)