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