Хорошая статья, понятно что правила в шахматах не так просты, чтобы их с наскоку реализовать. Но её ценность не в полноте, а в том что это хороший старт, например для учебных целей.
Лично я её так воспринимаю, а не как исчерпывающий движок.
Но это же не принципиально, ведь зачастую улица состоит из одного-двух слов, на триграммы или биграммы мы не разбиваем. Поэтому понятие «близости» поисковой фразы избыточно.
Гипотетически, оно пригодится если писать длинные поисковые фразы, которые могут включать в себя всё, от названия страны до строения, я бы всё равно смотрел в сторону настроек по умолчанию.
Первая проблема: заменить speech kit, Sphinx тут ни чем не поможет. (Есть ещё CMU Sphinx, это другое, мы про Sphinx Search) Можете посмотреть в строну webkitSpeechRecognition но он совместим далеко не со всеми браузерами.
Когда Вы переведёте голос в текст, то Sphinx его конечно сможет найти, если в вашей БД есть координаты то он вернёт и их и есть функция для работы с координатами можно с её помощью искать ближайших, сортировать по расстоянию и т.д.
Но вторая проблема: в выгрузках ФИАС нет координат, только адреса и идентификаторы, и куча всего, что они туда ещё напихали. Поэтому с геокодированием беда. У Яндекса есть яндекс.карты, он по ним и геокодирует, а у Sphinx есть только то, что вы ему скормите.
Как на свободный аналог Яндекс.Геокодинг можете посмотреть nominatim. Только его с ФИАС не скрестить, он с данными OSM работает, и адреса и координаты берёт там.
И бесплатные решения обычно бесплатны для тех, кто не ценит своё время. Может и не стоит отказываться от текущей реализации.
Ещё нет, надеюсь когда-нибудь дойдёт до прода, но от задумки до реализации… Может вообще положим под сукно.
А в докер не умею, каюсь — грешен. Мне бы Аредовы веки, на изучение.
Да, GraphHopper весьма гибок, можно и одни те же вещи делать по разному.
Мне ближе подход из примера LowLevelAPIExample, а то что Вы описываете похоже на пример RoutingExample где Weighting задаётся через Profile.
Спасибо за сервис, буду советовать тем кто приезжает в гости на пару дней.
Мне больше интересны технические детали реализации. В двух словах хотя бы.
Если я правильно понял, то используется graphhopper, с переписанным FootFlagEncoder? А приоритет меняли с помощью переписывания метода handlePriority?
Он вроде перебирает объекты по одному, и соседей учесть не получится. Или есть какой-то собственный метод-препроцессор который выполняет аппроксимации — строит буферные зоны, а потом Вы используете во FootFlagEncoder уже заранее рассчитанные веса?
Есть ли в graphhopper уже готовые подходящие методы для аппроксимаций и прочих проверок расстояний, или всё было написано самостоятельно?
Такой вариант есть, посмотрите документ Quickstart, нужно будет скачать уже готовый web service jar. После запуска получите аналог graphhopper.com/maps, взаимодействие с API можно на нём и посмотреть или в документации Routing API.
Я создаю своё Java приложение потому что хочу работать через низкоуровневое API, прошу прощения если ввёл в заблуждение.
Цена, мягко говоря, кусачая. К вам Тони Роббинс приезжает?
Лично я её так воспринимаю, а не как исчерпывающий движок.
Дефолтный, если не ошибаюсь, по умолчанию SPH_RANK_PROXIMITY_BM25 используется.
Но это же не принципиально, ведь зачастую улица состоит из одного-двух слов, на триграммы или биграммы мы не разбиваем. Поэтому понятие «близости» поисковой фразы избыточно.
Гипотетически, оно пригодится если писать длинные поисковые фразы, которые могут включать в себя всё, от названия страны до строения, я бы всё равно смотрел в сторону настроек по умолчанию.
Первая проблема: заменить speech kit, Sphinx тут ни чем не поможет. (Есть ещё CMU Sphinx, это другое, мы про Sphinx Search) Можете посмотреть в строну webkitSpeechRecognition но он совместим далеко не со всеми браузерами.
Когда Вы переведёте голос в текст, то Sphinx его конечно сможет найти, если в вашей БД есть координаты то он вернёт и их и есть функция для работы с координатами можно с её помощью искать ближайших, сортировать по расстоянию и т.д.
Но вторая проблема: в выгрузках ФИАС нет координат, только адреса и идентификаторы, и куча всего, что они туда ещё напихали. Поэтому с геокодированием беда. У Яндекса есть яндекс.карты, он по ним и геокодирует, а у Sphinx есть только то, что вы ему скормите.
Как на свободный аналог Яндекс.Геокодинг можете посмотреть nominatim. Только его с ФИАС не скрестить, он с данными OSM работает, и адреса и координаты берёт там.
И бесплатные решения обычно бесплатны для тех, кто не ценит своё время. Может и не стоит отказываться от текущей реализации.
А в докер не умею, каюсь — грешен. Мне бы Аредовы веки, на изучение.
Мне ближе подход из примера LowLevelAPIExample, а то что Вы описываете похоже на пример RoutingExample где Weighting задаётся через Profile.
Мне больше интересны технические детали реализации. В двух словах хотя бы.
Если я правильно понял, то используется graphhopper, с переписанным FootFlagEncoder? А приоритет меняли с помощью переписывания метода handlePriority?
Он вроде перебирает объекты по одному, и соседей учесть не получится. Или есть какой-то собственный метод-препроцессор который выполняет аппроксимации — строит буферные зоны, а потом Вы используете во FootFlagEncoder уже заранее рассчитанные веса?
Есть ли в graphhopper уже готовые подходящие методы для аппроксимаций и прочих проверок расстояний, или всё было написано самостоятельно?
Надеюсь это не коммерческая тайна.
Речь идёт именно про низкоуровневое API.
Вероятно метод вызывается несколько раз, в зависимости от количества этих промежуточных точек, а результат объединяется.
Если бы мне нужно было строить через промежуточные точки, я бы так и сделал, а потом объединил множество в один ответ.
Я создаю своё Java приложение потому что хочу работать через низкоуровневое API, прошу прощения если ввёл в заблуждение.