New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Call Taker Module - Stop Finder Bug #2279

Closed
msrichardson opened this Issue Jun 9, 2016 · 1 comment

Comments

Projects
None yet
2 participants
@msrichardson

msrichardson commented Jun 9, 2016

This is in the test version, not the TM production version.

When looking up a stop 'By Name', the results don't always display the most relevant options first, if at all. See below for two examples.

SE 17th (there are a number of stops on SE 17th, yet none show in the list (even when scroll to the bottom)
croppercapture 175

Salmon/SW Salmon -- in this case, stops with Salmon do show up, however I can't figure out how the very first option is a match.

croppercapture 176

demory added a commit that referenced this issue Oct 12, 2016

@demory

This comment has been minimized.

Member

demory commented Oct 12, 2016

Some updates on this issue:

First, note that, by default, the string matching library that OTP uses (Lucene) considers spaces to be delimiters between distinct search terms. So when you search for SE 17th, it is looking any stop name that includes both "SE" and "17th" anywhere in the name. Hence, results like "SE Stark and 217th".

I've made a change, just pushed to the test server, that allows you to use quotation marks to indicate multi-word search phrases. For example, searching for "SE 17th" (with quotes included as part of the search) should only return results that include the entire phrase.

Quoted phrases can be combined with standard unquoted terms, e.g. "SE 17th" lexington which should return any variations of the SE 17th & Lexington stop. (Note that OTP by default does an "or" search, meaning that you may see some results that only match one of these two, but any matches for both terms should be listed first.)

Also, quotes can be used around a single word to force Lucene to consider only the exact spelling of that term. (By default, it uses a "fuzzy" matching algorithm that finds matches similar to the search term as well as exact ones.)

For example, searching for salmon (without quotes) will return some "fuzzy" matches (apparently "Alton" is considered similar enough). But searching for "salmon" should only return those with that exact spelling.

Let me know if you have any questions or see anything that looks off with the new results.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment