СПОСОБ И СИСТЕМА ФОРМИРОВАНИЯ МАРШРУТА ПЕРЕДВИЖЕНИЯ ОТ ДВЕРИ ДО ДВЕРИ Российский патент 2023 года по МПК G01C21/34 G01C21/26 G06F16/00 G06Q50/10 

ОБЛАСТЬ ТЕХНИКИ

[001] Изобретение относится в общем к вычислительной области техники, а в частности к способам и системам планирования маршрута для передвижения, используя различные виды транспорта с заранее известной начальной точкой отправления и конечной точкой прибытия, учитывая различные параметры и критерии подбора видов транспорта, такие как время в пути, стоимость, время пересадок и другие. Способ предоставляет возможность составлять маршрут не только наземным транспортом, а также воздушным и морским.

УРОВЕНЬ ТЕХНИКИ

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

[003] Также в опубликованной заявке RU2571450C2 раскрывается устройства для построения мультимодальной навигации. Текущее местоположение путешественника по GPS синхронизируется с запланированным и в случае отклонения маршрута перестраивается. В заявке также сказано, что есть возможность использовать различные виды транспорта в городской среде: пешком, на автомобиле, на автобусе или метро. Предполагается что путешественник сам будет покупать билеты и заботиться о возможности перемещения тем или иным видом транспорта. Навигационная система только составляет маршрут.

[004] В заявке RU2572279C1 также раскрывается способ построения мультимодального маршрута. В данной заявке рассматривается наземный транспорт для городской среды с использованием автобусов, пеших маршрутов, самокатов.

[005] Утомительно каждый раз искать и подбирать маршруты для передвижения. При том, что выбор обычно падает на надежных поставщиков услуг и на привычные и однотипные варианты передвижения. Сложно вручную подбирать время стыковок маршрутов. Например, если в маршруте есть маршрут на электричке и время отправление в 19:00, то необходимо вручную подобрать перелет или такси для самого короткого ожидания. Также следует учитывать цену, класс транспорта и другие параметры. Могут быть личные предпочтения, такие как место в женском купе или такси с водителем-женщиной.

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

СУЩНОСТЬ ИЗОБРЕТЕНИЯ

[007] Настоящее изобретение включает в себя формирование маршрута передвижения пользователя из заранее известной точки отправления в заранее известную точку прибытия. Маршрут составляется автоматически с учетом критериев пользователя посредством использования алгоритмов машинного обучения. Также учитываются предпочтения пользователя на основе его “поведенческого портрета” пользователя.

[008] Изобретение предоставляет пользователю систему бронирования, которая подбирает маршрут по предпочтениям, и дает возможность забронировать все средства передвижения. От пользователя изобретения необходимо получить только точку отправления, точку прибытия и указать пользователя. Система предложит маршрут по параметрам автоматически.

[009] Техническим результатом, достигаемым в данном техническом решении, является повышение точности формирования маршрута передвижения от двери до двери за счет использования алгоритма поиска маршрута RAPTOR и алгоритмов машинного обучения.

[0010] Указанный технический результат достигается благодаря осуществлению способа формирования маршрута передвижения от двери до двери, который выполняется по меньшей мере одним вычислительным устройством и включает следующие шаги: получают от меньшей мере одного устройства пользователя запрос по протоколу HTTPS в JSON формате в сервис поиска d2d-service, находящийся на по меньшей мере одном сервере, причем запрос включает точный адрес места назначения; формируют по меньшей мере один маршрут посредством алгоритма RAPTOR на основании данных из запроса пользователя, полученного на предыдущем шаге; получают параметры поиска посредством использования рекуррентной искусственной нейронной сети, причем модель нейронной сети предсказывает эталонный маршрут на основании истории передвижения пользователя; осуществляют поиск маршрутов передвижения посредством запросов поставщикам маршрутов, причем найденные маршруты один за другим сравниваются с эталонным маршрутом методом косинусной близости; формируют по меньшей мере один маршрут передвижения пользования посредством фильтрации полученных на предыдущем шаге маршрутов передвижения.

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

[0011] На Фиг. 1 показан примерный вариант реализации способа передвижения от двери до двери в виде блок-схемы.

[0014] На Фиг. 2 показан вариант реализации, где данные из ответа сохраняются в реляционной БД, для быстрого доступа и быстрой выборки.

[0013] На Фиг. 3 показан вариант реализации интерфейса, на которой отображается карта, с помощью которой возможно задать координаты.

[0014] На Фиг. 4 показан вариант реализации алгоритма, который находит кратчайший путь, состоящий из набора маршрутов.

[0015] На Фиг. 5 показан вариант реализации финальной выдачи, которая формируется в сервисе aggregation-service и отправляется в сервис d2d-service.

[0016] На Фиг. 6 показан вариант реализации маршрутов и доступных вариантов передвижения от поставщиков.

ПОДРОБНОЕ РАСКРЫТИЕ ТЕХНИЧЕСКОГО РЕШЕНИЯ

[0017] Данное техническое решение представляет возможность искать варианты передвижения различными транспортами и способами (см. Фиг. 1).

[0018] На первом шаге способа осуществляют получение на сервере расписания от поставщиков. Поставщиком может являться сервис в сети Интернет, который предоставляет информацию о передвижении, например, транспортного средства. Для авиаперелетов существуют GDS (глобальная дистрибьютерская система), предоставляющая возможность поиска, бронирования авиабилетов. Самые известные в уровне техники системы GDS: Amadeus, Sabre, Galileo. Некоторые авиакомпании имеют свои собственные системы бронирования, они также могут выступать в роли поставщика. Так же в GDS есть информация о железнодорожных перевозках. Поставщиком для железнодорожных перевозок может выступать GDS или система бронирования от железнодорожных компаний. Для, например, России поставщиком услуг железнодорожных перевозок выступает РЖД, через интегратор Teletrain. Для гостиниц поставщиком выступают системы бронирования отелей, например, Островок, Броневик, A&A и др., в том числе зарубежные: Booking, Expedia. Для такси поставщиком может выступать агрегатор такси, работающий в стране использования, например, Яндекс.Такси, Uber. Для каждого поставщика услуг заранее делают интеграцию с ним.

[0019] Для составления маршрута необходимо знать все возможные варианты передвижения, т.е. расписание самолетов, поездов, электричек и аэроэкспресса. Эту информацию предоставляют поставщики услуг по API на основании предварительного запроса из данной системы.

[0020] Система построена на сервисно-ориентированной архитектуре. Каждый элемент системы отвечает за одну конкретную задачу и называется сервисом. Сервис для поиска делает запросы во все доступные поставщики по API. Формат запроса зависит от поставщика. Например, для поиска авиабилетов распространен протокол взаимодействия NDC. Так же может быть SOAP или REST в формате JSON, поверх HTTP. Данное техническое решение никак не ограничивает протоколы взаимодействия между системой и поставщиком. В ответ возвращается полное расписание в формате взаимодействия с поставщиками. В ответе есть точка отправления, точка прибытия, время отправления, время в пути, терминал отправления/прибытия, время перелета, номер рейса/номер поезда.

[0021] У каждого поставщика есть метод в API для получения расписания. Формат запроса и ответа зависит от конкретного поставщика. В общем виде это запрос без параметров. Для REST запросов будет выглядеть как Error! Hyperlink reference not valid.

[0022] Для SOAP

0023] В зависимости от поставщика, в ответе может быть файл с расписанием в формате CSV или JSON, или ответ в SOAP-формате.

[0024] Независимо от формата ответа, в ответе будут необходимые данные:

FlightNumber - номер рейса;

Departure - аэропорт отправления;

Arrival - аэропорт прибытия;

DepartureDate - дата и время отправления;

ArrivalDate - дата и время прибытия;

DepartureTerminal - терминал отправления;

ArrivalTerminal - терминал прибытия;

FlightDuration - время перелета.

[0025] Расписание сохраняется на сервере в реляционную БД со структурой (Фиг. 2). Отдельные таблицы используются для каждого поставщика.

create table segments_provider

[0026] Для ЖД-билетов алгоритм работает аналогичным образом. Сначала с помощью метода API получают все возможные поезда. Запрос справочника поездов вызывается без параметров. А в ответе будет список поездов.

<train_number>772АА</train_number>
<train_number>51Б</train_number>

<train_number>51Й</train_number>

[0027] По каждому поезду запрашивается его путь следования, методом получения информации о маршруте движения поезда.

[0028] В параметрах запроса указывается номер поезда: <train_number>772А</train_number>

[0029] В ответе получаем весь маршрут со всеми остановками

<route>МОСКВА ОКТ</route>

<route>С-ПЕТЕР-ГЛ</route>

<stop>

<station>МОСКВА</station>

<code>2000000</code>

<dep_time>19:30</dep_time>

<days>00</days>

</stop>

<stop>

<station>МОСКВА ОКТ</station>

<code>2006004</code>

<dep_time>19:30</dep_time>

<days>00</days>

</stop>

[0030] Где:

station - станция остановки;

code - код станции;

dep_time - время отправления;

days - день, если поезд едет более одного дня.

[0031] Эта данные сохраняются в реляционную БД в таблицу со схемой (Фиг. 2).

create table segments_provider

[0032] Обновление происходит раз в сутки, но также доступен ручной запуск обновления на случай ошибки или непредвиденных обстоятельств. Данные из ответа сохраняются в реляционной БД, для быстрого доступа и быстрой выборки (Фиг. 2). Для удобства поиска данных в конкретном примере реализации была выбрана реляционная БД. Альтернативой могут выступать колоночные БД, но в колоночных БД обновление/удаление элементов является дорогой операцией. В документно-ориентированных БД, поиск передвижения будет узким местом.

[0033] Выбор точки отправления и точки прибытия раскрывается более подробно ниже.

[0034] Для ввода параметров для поиска есть веб-интерфейс, с двумя текстовыми полями и двумя полями для ввода даты. Для ввода параметров так же доступна карта. Модуль карты может быть любой, например Яндекс.Карты, OpenStreetMaps. Яндекс карты подключаются следующим скриптом

<head>

<script src="https://api-maps.yandex.ru/2.1/?apikey=ваш API-ключ&lang=ru_RU"

type="text/javascript">

</script>
</head>

<meta name="viewport" content="initial-scale=1.0, user-scalable=no, maximum-scale=1" />

[0035] В интерфейсе находится карта, с помощью которой возможно задать координаты. Есть 2 текстовых поля, 2 кнопки, 2 поля для ввода даты, поле для выбора сотрудника и кнопка поиска (Фиг. 3).

[0036] Пользователь может вводить данные в поле ввода в формате <Страна> <Город> <Улица> <Дом>. По введенным символам система предлагает подходящие варианты поиска. Справочники для регионов и улиц хранятся в БД и индексируется СУБД ElasticSearch. Может использоваться любая другая СУБД, поддерживающая n-gram токенизацию. N-gram представляет из себя последовательность слов, букв, слогов. Для нечеткого поиска достаточно разделить словарь стран, городов, улиц на триграммы, т.е. по три символа. На основе этих триграмм можно определить какие из них встречаются часто. Например, триграмма «Мос» встречается часто, а «Мсо» нет, вероятней всего имели в виду «Мос». Такой подход позволяет искать записи в словаре даже если в слове есть ошибка/опечатка. БД заполняется странами, регионами (города, населенные пункты, села, деревни и т.п.), улицами и номерами домов. По России эти данные берутся из федеральной информационной адресной системы ФИАС, для остальных стран используется OpenStreetMap. Оба источника свободны для скачивания и использования. Обязательное условие, что поиск должен происходить в нижнем регистре. N-gram токенизация поддерживает ошибки в словах, если пользователь ошибется в написании одного из регионов, система сможет предложить правильный вариант.

[0037] Система предлагает два способа ввода параметров поиска. Первый - ввод точного адреса (описан выше). Второй - задать координаты на карте, используя веб-интерфейс. В качестве карт может выступать любой сервис, предоставляющий такую возможность: Яндекс.Карты, OpenStreetMap, Google Maps и т.п.

[0038] Составление графа передвижения осуществляется следующим образом.

[0039] На основе пункта отправления, пункта прибытия и расписания поставщиков составляется граф передвижения. Если пользователь указал координаты, то система находит ближайший населенный пункт с ЖД вокзалом или аэропортом. Для определения ближайшего населенного пункта используется СУБД PostgreSQL с расширением postgis. У этого расширения есть оператор «<->» который находит ближайшие точки:

[0040] Для составления конечного маршрута передвижения используется алгоритм RAPTOR. Для этого алгоритма загружаются параметры построения маршрута.

[0041] Алгоритм работает с параметрами (П, S, T, R, F).
П - Время в пути. Этот параметр нужен для контроля времени в пути, чтобы поездки укладывались в разумные сроки. Также этот параметр можно изменять для уменьшения времени путешествия.

[0042] S - Множество остановок. Набор точек пересадок. В нашем случае это будут все точки из общей выдачи. Другими словами, это все ЖД-станции и все аэропорты.

[0043] T - Множество поездок. Поездка - это одно предложение от поставщика. Либо определенный поезд, либо отдельный авиаперелет.

[0044] R - Выбор маршрутов. В одной поездке может быть несколько маршрутов. Например, одна поездка Пенза - Санкт-Петербург, но 2 маршрута Пенза - Москва и Москва - Санкт-Петербург. Другими словами, поездка может быть с пересадкой

[0045] F - Набор пересадок. В этом параметре задается множество пересадок, которые возможно сделать. Например, при пересадке в Москве, можно добраться из Аэропорта на ЖД вокзал и продолжить путешествие. Параметр F будет содержать в себе эту информацию. Другими словами, все возможные перемещения между ЖД-вокзалами и Аэропортами.

[0046] Параметр S. Заполняется всеми аэропортами и жд-вокзалами.

[0047] Параметр T. Из БД с расписанием строятся возможные поездки, т.е. это набор передвижений точка-точка без пересадки. У ЖД это станции по одному маршруту, у самолетов это города прямого авиасообщения и с пересадкой.

[0048] Параметр R. Маршруты. Поезда ходят по маршрутам, весь маршрут запишется в параметр R. У самолетов, маршрутом будет являться перелет, т.е. маршрут из 2х точек. Так же в этот пункт попадает аэроэкспресс, как маршрут, состоящий из 2х точек.

[0049] Параметр F. Набор точек для «пешего пути». В этот пункт попадают такси. Из исторических данных рассчитывается худшее время в пути, так же прибавляется один час, на возможность сойти с самолета или поезда, и на вызов такси.

[0050] Алгоритм находит кратчайший путь, состоящий из набора маршрутов (Фиг. 4).

[0051] На первом этапе выбирается коэффициент K - количество сегментов. Так как в данном алгоритме используются авиаперелеты и железнодорожные поезда, то будет разумным подобрать коэффициент K с небольшим значением. Большое количество пересадок сильно увеличит время поездки и в таких поездках не будет смысла. В конкретном примере реализации коэффициент алгоритма K=3. По статистике авиаперелет с двумя пересадки выбирают достаточно редко, проще выбрать либо другой транспорт без пересадок, либо рассмотреть другие варианты передвижения.

[0052] Алгоритм Raptor делает количество итераций, равное количеству пересадок. В каждой итерации выбираются все маршруты, проходящие через эту точку. В нашем случае это будет либо авиаперелет, либо жд-маршрут. На этом этапе проверяется возможно ли успеть на новый рейс. На первой итерации это не пригодится, в дальнейшем от времени прибытия будет зависеть подходит маршрут или нет. Подходящие маршруты сохраняются в список маршрутов для следующих преобразований.

[0053] На следующем этапе отмечаются все точки маршрута не раньше, чем время прибытия текущего маршрута. Таким образом мы имеем список маршрутов и остановок, подходящих для перемещения. Следующей итерацией фильтруются маршруты и остановки исходя из найденных маршрутов и остановок на прошлой итерации. После K-итераций останутся маршруты, подходящие для передвижения.

[0054] Сканирование маршрутов от остановки ps до pt раскрывается ниже.

[0055] На первой итерации сканируется маршрут r1, на второй r2 и r3, на третьей r4.

[0056] На каждой итерации составляется набор поездок, состоящих из маршрутов и пересадок.

[0057] Алгоритм RAPTOR на выходе даст набор поездок. Далее исключаем из набора поездки, не содержащие начальный и конечный пункт ps и pt. Таким образом останутся только те поездки, которые гарантированно доставят из пункта ps в пункт pt.

[0058] Зная время отправления и прибытия на каждой пересадке, система считает суммарное время поездки и выбирает наименьшее время в пути, т.е. самый быстрый маршрут.

[0059] Затем системе необходимо сделать запрос к поставщикам. Критерии поиска подбираются индивидуально. В окне интерфейса есть поле для выбора путешественника. На основе его прошлых поездок подбираются критерии поиска.

[0061] Для обучения искусственной нейронной сети используются исторические данные всех пользователей. Поездки за все время группируются по пользователю. Т.е. у каждого пользователя будет свой набор поездок.

[0061] Для предсказания будущей поездки может использоваться нейронная сеть RNN (рекуррентная нейронная сеть) класса LSTM (долгая краткосрочная память). Рекуррентная нейронная сеть позволяет предсказывать следующий элемент на основе набора элементов. В данном случае будет находиться вариант поездки на основе прошлых поездок.

[0062] Сгруппированные поездки разделяются на блоки по 5 + 1 поездок. Минимум с пяти поездок возможно предсказать следующую поездку.

[0063] Для обучения необходимо подготовить данные.

[0064] Векторное представление строки формируется как:

def vectorize(self, text)

[0065] Для каждого символа задается свое числовое представление, которое является кодом utf-8, которое возвращается в виде вектора (массива). Для подготовки чистых входных данных используется метод Vectorizer.word_tokenize из библиотеки keras.

[0066] Подготовленными данными обучается модель машинного обучения на основе LSTM нейросетей, где входными данными будет список векторов с параметрами, а выходным значением будет следующая поездка.

[0067] В нейросети будет использоваться 2 слоя: LSTM и Dense.

[0068] LSTM слой отвечает за обучение и предсказание с функцией активации relu. Relu-функция возвращает 0, если принимает отрицательный аргумент, в случае же положительного аргумента, функция возвращает само число. Функция активации будет возвращать значение параметра, а не его вероятность.

[0069] Dense - скрытый слой, который нужен для вычисления конечного результата.

[0070] Сгруппированные по пользователю поездки представлены в виде массива. Для обучения нейронной сети, проходим по всему списку поездок, берем 5 поездок для прошлых поездок и 6-ю поездку для выходного значения. Сдвигаемся на одну поездку, и снова берем 5 поездок.

[0071] Входные данные:

a. Количество пересадок - 0, 1, 2;

b. Код тарифа - число;

Код авиакомпании - векторное представление строки;

c. Наличие багажа - 0, 1;

Код аэропорта отправления - векторное представление строки;

d. Код аэропорта прибытия - векторное представление строки;

e. Время в пути в секундах - число;

f. Время вылета в секундах;

g. Авиакомпания - векторное представление строки.

[0072] Выходные данные:

[количество пересадок, код тарифа, время вылета в секундах, время в пути в секундах, авиакомпания]

[0073] Из выходной модели исключены аэропорты вылета и прилета, т.к. нам уже известны эти данные.

[0074] Подготовленными данными нейронная сеть обучается. Готовая модель сохраняется для дальнейшего использования на сервере. Определение подходящих вариантов перелетов раскрывается ниже.

[0075] Для работы алгоритма у пользователя должно быть не менее пяти поездок. Сначала делается поиск у поставщиков на данное направление и дату. Затем по 5ти последним поездкам пользователя модель нейронной сети предсказывает следующий маршрут, причем этот маршрут считается “эталонным” для этого пользователя.

[0076] Найденные маршруты один за другим сравниваются с эталонным маршрутом методом косинусной близости. С помощью него можно достаточно точно определить, насколько похож вариант из выдачи на эталонный маршрут.

[0077] Пример кода на python для нахождения косинусного расстояния

from numpy import dot

from numpy. linalg import norm

cos_sim = dot (a, b)/( norm (a)\* norm (b))

[0078] Выбирается, например, пять самых близких поездок, для возможности выбора, на случай если нейронная сеть ошиблась или у пользователя изменились планы и предпочтения.

[0079] Для ЖД-билетов алгоритм отличается только входной и выходной моделями.

[0080] Входная модель выглядит так:

○ Тип вагона - число с кодом типа вагона

○ Код перевозчика - векторное представление строки

Время отправления

○ Номер поезда - число с кодом номера поезда

○ Время в пути в секундах - число

○ Вокзал отправления - векторное представление строки

○ Вокзал прибытия - векторное представление строки

○ Время вылета в секундах

○ Авиакомпания - векторное представление строки.

[0081] Выходная модель:

[0082] [Тип вагона, код перевозчика, время отправления, номер поезда, время в пути в секундах]

[0083] Из выходной модели исключены вокзал отправления и вокзал прибытия.
Текстовые данные аналогично текстовым данным в авиабилетах, представляются в виде векторов чисел с помощью функции word_tokenize.

[0084] С доверительной вероятностью 95% можно утверждать, что максимальное число бронирований для полной идентификации будет равно 5, то есть уже с 6-го бронирования для каждого пользователя можно достаточно точно предугадывать подходящие варианты передвижения.

[0085] Имея кратчайший путь и параметры для поиска, система делает запросы ко всем поставщикам с заданными параметрами.

[0086] Формат запросов к поставщику зависит от поставщика. В общем случае может быть REST, SOAP или в бинарном формате со своей структурой сообщения работающая поверх протокола TCP.

[0087] Следующие параметры в запросы являются обязательными:

Departure - аэропорт отправления;

Arrival - аэропорт прибытия;

Date - дата отправления;

Class - класс перелета;

TravellerCount - количество человек.

[0088] Возможны дополнительные параметры, например авиакомпания или тип перевозчика. В конкретном примере реализации они не пригодятся.

[0089] В формате поставщика формируется запрос и отправляется поставщику. В ответ возвращаются варианты перелета.

[0090] Т.к. поставщики имеют разные форматы в своих API, то форматы будут разные. У всех поставщиков можно выделить обязательные данные в ответе, необходимые для бронирования.

○ DepartureDate - дата и время вылета

○ ArrivalDate - дата и время вылета AirlineCompany - авиакомпания Duration - время в пути Fare - тариф Price - цена

[0091] Для ЖД-билетов запросы отправляются схожим образом с АБ. Формат запроса зависит от поставщика. В общем виде, к поставщику отправляются

from - станция отправления

to - станция прибытия

date - дата отправления

[0092] В ответ возвращается доступные билеты на указанную дату.

number - номер поезда

type - тип перевозчика

departure_date - дата отправления

departure_time - время отправления

arrival_date - дата прибытия

arrival_time - время прибытия

travel_time - время в пути

eregistration - флаг электронной регистрации

Так же приходят свободные места в поезде:
type - тип места (плацкартный, купэ)

free_seats - количество свободных мест

class_service - класс вагона

tariff - стоимость

[0093] Этих данных достаточно для дальнейшего составления маршрута.

[0094] Класс перелета и авиакомпанию указывает на этапе поиска. Одинаковые результаты поиска агрегирует по цене, оставляя самый дешевый вариант.

[0095] Система подбирает два варианта маршрутов: самый подходящий и самый дешевый.

[0096] Алгоритмом быстрой сортировки результаты поиска сортируются по цене и выбираются самые дешевые варианты. Из этих результатов составляется «самый дешевый» вариант.

[0097] Для «самого подходящего», система оставляет только варианты, подходящие под критерии поиска, т.е. фильтрует по параметрам тип вагона, флаг пересадки, багаж, возможность возврата, авиакомпания. Проходит по всем результатам поиска и оставляет только варианты, подходящие по параметрам. Так же как в варианте с «самым дешевым» выбираются самые дешевые варианты.

[0098] Если пользователя устраивают условия передвижения, то этот маршрут можно положить в корзину и забронировать. Бронирование проходит в автоматическом режиме. Т.е. не нужно бронировать каждую услугу, на данном этапе хватает всех данных, чтобы выкупить все услуги из поездки.

[0099] Система построена на сервисно-ориентированной архитектуре. Может работать как на виртуальных серверах, так и быть развернута в облачных хостингах. Доступ к системе осуществляется через веб-интерфейс по защищеному протоколу HTTPS. Внутри системы сервисы обмениваются данными по протоколу gRPC.

[00100] Параметры для поиска приходят в сервис поиска d2d-service.

[00101] D2d-service - это сервис, находящийся на серверах и входящий в состав системы. Он отвечает за поиск в целом и за обмен информацией с клиентской частью системы.

[00102] От клиента, веб-интерфейса, приходит запрос по протоколу HTTPS в JSON формате.

где

DepartureId - id-точки отправления

ArrivalId - id-точки прибытия

TravellerId - путешественник

DepartureLoc - объект с координатами точки отправления

ArriavalLoc - объект с координатами точки прибытия

Date - дата отправления

[00103] Запрос приходит в d2d-service. Затем d2d-service проверяет, стоит DepartureId и ArrivalId, если эти параметры установлены, из справочника получаются координаты пунктов отправления и прибытия. Справочник находится в реляционной БД. Данные забираются SQL-запросом.

SELECT * FROM AirlineDictionary WHERE id = <DepartureId>

[00104] Иначе координаты берутся из DepartureLoc и ArrivalLoc. Если не установлены DepartureLoc и ArrivalLoc, запрос считается невалидным и возвращается ошибка. TravellerId необходим для подбора рекомендаций. Подготовленные данные передаются в сервис route-engine.

[00105] Затем управление передается в route-engine, который забирает из БД расписание на выбранные даты и строит маршрут по алгоритму RAPTOR. Сервисная архитектура позволяет заменять алгоритм на другой подходящий. Построенные маршруты передаются в сервис recommendation-service, который на основе нейронных сетей подбирает подходящие варианты на основе обученной модели. Подготовленные маршруты передаются в search-service, который запрашивает информацию о свободных местах и ценах у поставщиков. Финальная выдача формируется в сервисе aggregation-service и отправляется в сервис d2d-service. (Фиг. 5). Маршруты и доступные варианты передвижения от поставщиков, как показано на Фиг. 6, передаются в recommendation-service, где все варианты проверяются на соответствие “портрету” пользователю. Рассчитывается косинусное расстояние, описанное выше, причем всех вариантов, и сравнивается с предсказанным моделью, вариантом передвижения наилучшие варианты сохраняются в выходную модель.

Изобретение относится к способу планирования маршрута для передвижения, используя различные виды транспорта. Способ формирования маршрута передвижения от двери до двери, выполняемый вычислительным устройством, включает следующие шаги: получение от устройства пользователя запрос в сервис поиска, находящийся на сервере, причем запрос включает точный адрес места назначения, получение на сервере расписания от поставщиков, формирование маршрута посредством алгоритма RAPTOR на основании данных из запроса пользователя, запрашивание информации о свободных местах и ценах у поставщиков на основании подготовленных маршрутов, получение параметров поиска посредством использования рекуррентных искусственных нейронных сетей, которые предсказывают следующий эталонный маршрут для пользователя, сравнение одного за другим найденных маршрутов с эталонным маршрутом, формирование маршрута передвижения пользования посредством фильтрации полученных на предыдущем шаге маршрутов передвижения, бронирование маршрута в автоматическом режиме. Достигается повышение точности формирования маршрута передвижения от двери до двери. 6 ил.

Способ формирования маршрута передвижения от двери до двери, выполняемый по меньшей мере одним вычислительным устройством и включающий следующие шаги:

получают от по меньшей мере одного устройства пользователя запрос по протоколу HTTPS в JSON формате в сервис поиска d2d-service, находящийся на по меньшей мере одном сервере, причем запрос включает точный адрес места назначения;

осуществляют получение на сервере расписания от поставщиков;

формируют по меньшей мере один маршрут посредством алгоритма RAPTOR на основании данных из запроса пользователя, полученного на предыдущем шаге, при этом система считает суммарное время поездки и выбирает самый быстрый маршрут;

запрашивают информацию о свободных местах и ценах у поставщиков на основании подготовленных маршрутов;

получают параметры поиска посредством использования рекуррентных искусственных нейронных сетей, которые позволяют предсказывать следующий элемент на основе прошлых поездок пользователя, при этом для работы алгоритма у пользователя должно быть не менее пяти поездок на данное направление, по которым модель нейронной сети предсказывает следующий эталонный маршрут для пользователя;

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

формируют по меньшей мере один маршрут передвижения пользования посредством фильтрации полученных на предыдущем шаге маршрутов передвижения, причем

если пользователя устраивают условия передвижения, то этот маршрут можно забронировать в автоматическом режиме.