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: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.
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: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...)