organicmaps/organicmaps-tmp

Archived

Fork 1

[search] Avoid fancy categories matching. #4276

Merged

vng merged 2 commits from vng-fix into master

2023-01-19 18:12:32 +00:00

vng commented

2023-01-14 16:38:09 +00:00

(Migrated from github.com)

organicmaps/organicmaps#3655

https://git.omaps.dev/organicmaps/organicmaps/issues/3655

👍 1 🎉 1

biodranik (Migrated from github.com) reviewed 2023-01-14 18:26:58 +00:00

biodranik (Migrated from github.com) left a comment

Это костыль, который не решает случаи >4.
- Для категорий фуззи матчинг часто выглядит непонятно и не логично, вызывая отторжение, т.к. он работает по всем вариантам слов, а не только по отображаемому названию.
- Фуззи матчит результаты, вместо того, чтобы подсвечивать "возможно имевшиеся ввиду" подсказки категорий.

Т.е. кошерная реализация могла бы фуззить только +-1 символ в именах объектов (ожидаемо, там где юзеры часто ошибаются, особенно на незнакомых языках), а для категорий делать только подсказку синих, возможно имевшихся ввиду синонимов, да и то, только если не было полнонго матча на хотя бы одну категорию. При этом можно жирным и не жирным подсвечивать очепятки в подсказках.

Починить тест
Running world_feed_tests.cpp::Transit_GTFS_ProjectStopToLine_Simple
FAILED
world_feed_tests/world_feed_tests.cpp:237 TEST(ResT(5, false) == PrepareNearestPointOnTrack(point_C, std::nullopt, shape.size() , Direction::Backward, shape)) (5, 0) (6, 0)

1. Это костыль, который не решает случаи >4. - Для категорий фуззи матчинг часто выглядит непонятно и не логично, вызывая отторжение, т.к. он работает по всем вариантам слов, а не только по отображаемому названию. - Фуззи матчит результаты, вместо того, чтобы подсвечивать "возможно имевшиеся ввиду" подсказки категорий. Т.е. кошерная реализация могла бы фуззить только +-1 символ в именах объектов (ожидаемо, там где юзеры часто ошибаются, особенно на незнакомых языках), а для категорий делать только подсказку синих, возможно имевшихся ввиду синонимов, да и то, только если не было _полнонго_ матча на хотя бы одну категорию. При этом можно жирным и не жирным подсвечивать очепятки в подсказках. 3. Починить тест Running world_feed_tests.cpp::Transit_GTFS_ProjectStopToLine_Simple FAILED world_feed_tests/world_feed_tests.cpp:237 TEST(ResT(5, false) == PrepareNearestPointOnTrack(point_C, std::nullopt, shape.size() , Direction::Backward, shape)) (5, 0) (6, 0)

vng commented

2023-01-14 20:16:10 +00:00

(Migrated from github.com)

Это про search in viewport, там нет "возможно имевшиеся ввиду" подсказки. Для списка результаты с ошибками и так будут далеко в самом низу
"(+-1) символ в именах объектов (ожидаемо, там где юзеры часто ошибаются, особенно на незнакомых языках)" - если это пытаться формализовать в алгоритм, то можно годами пилить. И один символ очевидно мало.

Это не идеальный, но в целом приемлемый фикс. Лучше примеры нерабочих запросов для предметного обсуждения.

- Это про search in viewport, там нет "возможно имевшиеся ввиду" подсказки. Для списка результаты с ошибками и так будут далеко в самом низу - "(+-1) символ в именах объектов (ожидаемо, там где юзеры часто ошибаются, особенно на незнакомых языках)" - если это пытаться формализовать в алгоритм, то можно годами пилить. И один символ очевидно мало. Это не идеальный, но в целом приемлемый фикс. Лучше примеры нерабочих запросов для предметного обсуждения.

vng commented

2023-01-14 20:51:47 +00:00

(Migrated from github.com)

Тут я еще буду экспериментировать с lower bound threshold, какие результаты уже не стоит показывать в search-in-viewport.

Еще можно заполнять dfa для категорий, если производные в свою очередь не являются тоже категориями. Так вроде логичнее, но код станет более заковыристым ..

Тут я еще буду экспериментировать с lower bound threshold, какие результаты _уже_ не стоит показывать в search-in-viewport. Еще можно заполнять dfa для категорий, если производные в свою очередь не являются тоже категориями. Так вроде логичнее, но код станет более заковыристым ..

biodranik commented

2023-01-14 22:00:27 +00:00

(Migrated from github.com)

Это про search in viewport, там нет "возможно имевшиеся ввиду" подсказки.

Верно. Но про подсказки в списке ты согласен?

И в списке, и на карте не должно быть никаких фуззи результатов по "похожим в написании" категориям. Вообще. 0. Не зависимо от длины слова. Если ты с этим утверждением не согласен, то объясни почему, желательно, с реальными и полезными примерами. Моё мнение — если в результатах пусто, то взгляд идёт на запрос, и человек его исправляет на правильный. Вместо того, чтобы тыкать/скроллить что-то "похожее" на разных языках.

Дополнительный бонус от "пусто в результатах" — мы там сейчас будем подсказывать человеку про ОСМ и про как пользоваться поиском.

Для списка результаты с ошибками и так будут далеко в самом низу

У нас не будет далеко. К сожалению, наш список короткий, всего 20 результатов. В этом тоже большая проблема.

"(+-1) символ в именах объектов (ожидаемо, там где юзеры часто ошибаются, особенно на незнакомых языках)" - если это пытаться формализовать в алгоритм, то можно годами пилить. И один символ очевидно мало.

Сложно формализовать в алгоритм +-1 символ? Моё пояснение было не про алгоритм, а про пользу +-1.

И почему один символ "очевидно" мало? Этого вполне достаточно для большинства кейзов, и мусора тоже будет уже достаточно.

Это не идеальный, но в целом приемлемый фикс. Лучше примеры нерабочих запросов для предметного обсуждения.

Ты выбрал несколько отрепорченных пользователями ошибок. А сколько ещё не зарепорченных? Прогони алгоритм по categories.txt с разными языками, и сам увидишь, где уже +-1 вызывает коллизию, не говоря про +-2.

Тут я еще буду экспериментировать с lower bound threshold, какие результаты уже не стоит показывать в search-in-viewport.

Повторюсь, на мой взгляд фуззи категории — никакие не нужно показывать, ни во вьюпорте, ни в списке. Только их в виде синих подсказок в списке, чтобы пользователь явно тыкнул, что он хотел, не глядя на опечатку. Так ты действительно поможешь пользователю.

Буду рад услышать веские аргументы, почему фуззи категории таки стоит показывать во вьюпорте и в списке.

Еще можно заполнять dfa для категорий, если производные в свою очередь не являются тоже категориями. Так вроде логичнее, но код станет более заковыристым ..

Это о чём? Пояснишь?

> Это про search in viewport, там нет "возможно имевшиеся ввиду" подсказки. Верно. Но про подсказки в списке ты согласен? И в списке, и на карте _не должно быть_ никаких фуззи результатов по "похожим в написании" категориям. Вообще. 0. Не зависимо от длины слова. Если ты с этим утверждением не согласен, то объясни почему, желательно, с реальными и полезными примерами. Моё мнение — если в результатах пусто, то взгляд идёт на запрос, и человек его исправляет на правильный. Вместо того, чтобы тыкать/скроллить что-то "похожее" на разных языках. Дополнительный бонус от "пусто в результатах" — мы там сейчас будем подсказывать человеку про ОСМ и про как пользоваться поиском. > Для списка результаты с ошибками и так будут далеко в самом низу У нас не будет далеко. К сожалению, наш список короткий, всего 20 результатов. В этом тоже большая проблема. > "(+-1) символ в именах объектов (ожидаемо, там где юзеры часто ошибаются, особенно на незнакомых языках)" - если это пытаться формализовать в алгоритм, то можно годами пилить. И один символ очевидно мало. Сложно формализовать в алгоритм +-1 символ? Моё пояснение было не про алгоритм, а про пользу +-1. И почему один символ "очевидно" мало? Этого вполне достаточно для большинства кейзов, и мусора тоже будет уже достаточно. > Это не идеальный, но в целом приемлемый фикс. Лучше примеры нерабочих запросов для предметного обсуждения. Ты выбрал несколько отрепорченных пользователями ошибок. А сколько ещё не зарепорченных? Прогони алгоритм по categories.txt с разными языками, и сам увидишь, где уже +-1 вызывает коллизию, не говоря про +-2. > Тут я еще буду экспериментировать с lower bound threshold, какие результаты уже не стоит показывать в search-in-viewport. Повторюсь, на мой взгляд фуззи категории — никакие не нужно показывать, ни во вьюпорте, ни в списке. Только их в виде синих подсказок в списке, чтобы пользователь явно тыкнул, что он хотел, не глядя на опечатку. Так ты действительно _поможешь_ пользователю. Буду рад услышать веские аргументы, почему фуззи категории таки стоит показывать во вьюпорте и в списке. > Еще можно заполнять dfa для категорий, если производные в свою очередь не являются тоже категориями. Так вроде логичнее, но код станет более заковыристым .. Это о чём? Пояснишь?

vng commented

2023-01-15 11:27:56 +00:00

(Migrated from github.com)

"Еще можно заполнять dfa для категорий, если производные в свою очередь не являются тоже категориями."
это лучше решает вот это
"Прогони алгоритм по categories.txt с разными языками, и сам увидишь, где уже +-1 вызывает коллизию, не говоря про +-2."

Мне непонятно почему ты так настаиваешь, что категории прям никак не должны матчится с ошибками. Категории могут быть в запросе не сами по себе, а в контексте вместе с именами и улицами. Тут никакой подсказкой не решится. И да, я например пишу "ветеринар" с ошибками :) "Еще можно заполнять dfa для категорий, если производные в свою очередь не являются тоже категориями." это лучше решает вот это "Прогони алгоритм по categories.txt с разными языками, и сам увидишь, где уже +-1 вызывает коллизию, не говоря про +-2."

biodranik (Migrated from github.com) approved these changes 2023-01-15 16:00:53 +00:00

biodranik (Migrated from github.com) left a comment

Обсудили оффлайн.

Fuzzy categories нужны для двух случаев:

Поддержки окончаний, когда пользователь ввёл "магазины", а у нас в categories.txt есть "магазин" organicmaps/organicmaps#4282
Случайные очепятки в любой части слова. organicmaps/organicmaps#4284

Обсудили оффлайн. Fuzzy categories нужны для двух случаев: 1. Поддержки окончаний, когда пользователь ввёл "магазины", а у нас в categories.txt есть "магазин" https://git.omaps.dev/organicmaps/organicmaps/issues/4282 2. Случайные очепятки в любой части слова. https://git.omaps.dev/organicmaps/organicmaps/issues/4284

This repo is archived. You cannot comment on pull requests.

No reviewers

biodranik