iRail
Typeahead search order (Enhancement)
Hi, I only recently discovered the iRail website (after finding out about the recent developments in open-data at NMBS), nice work! Although, while looking around on the website I noticed some weird behavior while using the type-ahead feature. For example: when searching for station Ekeren, typing in the first 2 letters 'Ek' results in a list showing:
- Schaarbeek/Schaerbeek
- Etterbeek
- Lebbeke
- Dilbeek
- Essene-Lombeek
- Brussels-Chapelle/Brussels-Kapellekerk
Not really what i was looking for ... As chances are slim that someone would try finding his/her destination station by typing some of its middle letters, this behavior sort of makes the type-ahead feature useless imho.
I traced this behavior down to the regex filter in the iRail/stations repo.
Some fiddling around with the regexp (I'm far from a regex-wizard ...) shows that changing '/.*'.$query.'.*/i' to '/.*\\b'.$query.'.*/i' would drastically improve accuracy (for the hyperrail use-case).
Typing 'Ek' would result in:
- Ekeren
- Eke-Nazareth
Although I'm aware that you may want to keep the 'broad-search' functionality in the stations api, there's some room for improvement for it's use in the hyperrail-app ...
I'd be happy to file a pull-request after hearing some thoughts on this ...
Michaël
I think the filter isn't the problem, its more about sorting the results and getting the relevant solution at the top.
I believe you have a fair point to return results based on the first letters. We're also adding a vehicleFrequency to every station (https://github.com/iRail/stations/pull/76), so these two solutions together would make the typeahead much quicker.
As @avdg stated, sorting after filtering (currently the filter is stopped after a maximum of 6 results ...) may be an even better (but more complex) solution. When going this way I would suggest using a suggestion engine (Bloodhound, part of Twitter's Typeahead.js works really well ...) to take care of things. It also offers other useful functionalities such as debouncing (request rate limiting), prefetching and caching.
Will merge the pull request that comes up with a good solution for this. I'm not opinionated on how exactly it should work :)
It's taking lots of time to get my implementation done. There is a lot of details to think about and side-effects to consider, but at least I guess I'm half way done now.