РАЗРАБОТКА СЕРВИСА СБОРА, ОБРАБОТКИ И ВИЗУАЛИЗАЦИИ ТУРИСТИЧЕСКИХ ДАННЫХ

Введение

Туристическая индустрия оказывает значительное экономическое влияние на регионы, формируя местами основную строку прибыли. Ведение бизнеса на подобных территориях неразрывно связано с постоянным анализом сферы, результатом которого является определение туристических маршрутов, областей максимального скопления туристов. Необходимость в обработке всех туристических объектов города делает задачу невозможной для ручного решения. Автоматизация в сборе, обработке, визуализации данных туристической тематике для последующего анализа видится актуальной.

Предлагается разработать самостоятельный сервис для построения тепловой карты произвольного города мира на основе данных туристической тематики.

Картографический сервис

Реализация приложения начинается с поиска сервиса картографии для визуализации данных, построения слоя тепловой карты, к которому предъявляется набор требований:

• Наличие API для взаимодействия на стороне клиентской и серверной
• Допустимые квоты на API ограничения для бесплатного использования
• Мировое покрытие

Детальный анализ рынка среди Yahoo Maps, Bing Maps, Яндекс Карты, Open Street Map привел к выбору сервиса компании Google. Google Maps обладают мировым покрытием, многомиллионной публикой, не являются территориально ориентированными в отличии от Яндекс Карт и Yahoo Maps.

Первым шагом была произведена регистрация приложения в экосистеме Google для получения уникального секретного ключа, необходимого при выполнении обращений по REST [1]. Базовая реализация с отображением стандартной Google карты взята с сайта компании [2].

Геодезия

Для проведения математических расчетов между координатами с учетом особенностей поверхности Земли используется библиотека geocalc, которая подключается в качестве jar фала к приложению [3]. Реализован утилитный класс, сквозь который осуществляется взаимодействие с методами библиотеки. В основе любой высокоуровневой функции лежат две базовые:

1. Поиск расстояние между двумя точками
2. Нахождение точки на карте, отстающей от текущей на определенное расстояние в заданном направлении

Вычисления базируются на формулах Винсенти и Хаверсина [4].

Геокодирование

Первая задача, решаемая пользователем при открытии страницы сервиса в браузере – это нахождение интересующего геообъекта, города. Во избежание ручного поиска города на карте был реализован специальный интерфейс, базируясь на функциональных возможностях сервиса Google Maps Geolocation API [5].

Приложение пытается узнать текущие координаты пользователя на стороне браузера с помощью интерфейса JavaScript Windows Navigator [6]. При поддержке функциональности браузером и согласии пользователя на доступ к геолокации приложением будет получена пара координат, которые отправляются на сервер по REST для преобразования в объект типа город.

Рисунок 1. Схема процедура геокодирования пользователя

Контроллер передает координаты на сервис, который средствами Google Maps Geolocation API получает набор объектов, которые соответствуют текущим координатам, среди которых находится название страны, города, а также данные, задающие объект прямоугольной формы вокруг города, границы. Далее происходит сохранение объекта в СУБД PostgreSQL.

Рисунок 2. Автоматическое геокодирование пользователя из г. Санкт-Петербург

Текстовое поле, выделенное отдельно на рисунке 2, несет основную логику по навигации к произвольному городу мира и является специально сконфигурированным объектом google.maps.places.Autocomplete сервиса Google Maps Geolocation API [7]. Начав ввод интересующего города мира, сервис автоматически подсказывает различные варианты, выбор, одного из которых приведет к сведению к выбранному города и соответствующей записи на стороне сервера, для последующего пере использования.

Рисунок 3. Пример работы текстового поля с функцией авто дополнения при значении “Saint” и последующим выбора города Saint Paul MN, USA

Сбор данных

Источниками данных туристической тематики с мировым покрытием стали лидеры рынка, сервисы Google Maps и Foursquare, которые обладают API интерфейсом и базами данных на сотни гигабайт, часть объектов из которых необходимы. Оба источника могут отдать не более 20 и 30 объектов-мест соответственно в заданной области за один API запрос [8, 9].

Анализ выявил, что подобные задачи сбора данных с малыми жесткими ограничениями источников решаются наложение сетки на области поиска с заранее известным шагом, внутри которого 100% гарантия наличия мест, не превышающих API ограничения.

Невозможность предугадать, рассчитать шаг сетки для произвольного города мира делает данный подход невозможным. Также отдельно стоит отметить факт, что, наложив сетку 26х26 на г. Санкт-Петербург получим ячейки размера 1x1.7км² и необходимость сделать 26 * 26 = 676 запросов для покрытия всей области поиска. Гарантия полноты данных отсутствует, некоторая “популярная ячейка” может в действительности содержать гораздо больше мест, чем то, максимально возможное количество, которое отдает внешний сервис.

Для решения поставленной задачи сбора данных был разработан собственный алгоритм на основе структуры данных “дерево квадрантов”, который обладает сравнительно простой реализацией и, самое главное, предоставляет гарантию полноты по данным [10, c. 243].

Рисунок 4. Схематическое описание алгоритма сбора данных на основе дерева квадрантов

Алгоритм фиксирует область поиска (bounding box, прямоугольник), производит API запрос к внешнему сервису и ,в зависимости от количества данных в ответе, завершает работу с текущей зоной поиска или ,если количество мест максимально возможное, делит прямоугольную область поиска на четыре четверти SW, NW, NE, SE (юго-западную, северо-западную, северо-восточную, юго-восточную) рекурсивно повторяя алгоритм для каждой.

Рисунок 5. Алгоритм сбора данных на основе дерева квадрантов с сервиса Foursquare по категории “Музеи” для г. Санкт-Петербург

Ячейки накрывают регион вокруг города целиком и не пропускает ни одного места.

Построение тепловой карты

Для построения тепловой карты был произведен анализ алгоритмов кластерного анализа семейства K-Means, которым на вход подавались прямоугольные ячейки с суммарным значением рейтингов мест внутри них, с последующим обучением на них для сопоставления цветов. Позже была произведена доработка, когда туристический объект давал вклад не только в “свою ячейку”, но и в соседние, но с меньшим значением.

Рисунок 6. Результат алгоритма построения тепловой карты на базе алгоритмов семейства K-Means для г. Санкт-Петербург

Далее была произведена интеграция с фреймворком heatmap.js для построения тепловой карты в основе которого применяются алгоритмы градиентного анализа [12].

Рисунок 7. Результат работы фреймворка heatmap.js для г. Санкт-Петербург

Список литературы:

1. URL: https://developers.google.com/maps (дата обращения: 21.04.2018)
2. URL: https://developers.google.com/maps/documentation/javascript/tutorial (дата обращения: 22.04.2018)
3. URL: https://github.com/grumlimited/geocalc (дата обращения: 30.03.2018)
4. URL: https://en.wikipedia.org/wiki/Vincenty%27s_formulae (дата обращения: 14.04.2018)
5. URL: https://developers.google.com/maps/documentation/geolocation (дата обращения: 20.04.2018)
6. URL: https://developer.mozilla.org/en-US/docs/Web/API/Window/navigator (дата обращения: 18.02.2018)
7. URL: https://developers.google.com/maps/documentation/javascript/examples/places-autocomplete (дата обращения: 13.03.2018)
8. URL: https://developers.google.com/maps/documentation/javascript/usage (дата обращения: 21.03.2018)
9. URL: https://developer.foursquare.com/docs/api/troubleshooting/rate-limits (дата обращения: 27.03.2018)
10. Стивенс Р. Алгоритмы. Теория и практическое применение: 2018. – 243 c.
11. Шульга Т., Данилов Н. Построение тепловой карты на основе точечных данных об активности пользователя приложения: 2017.
12. URL https://www.patrick-wied.at/blog/the-inner-life-of-heatmap-js (дата обращения: 17.04.2018)