В данной статье описывается создание web-сервиса для проверки уровня безопасности построенного маршрута. Метод анализа построенного маршрута для водителя и пешехода представлен на конференции «Технические науки: проблемы и перспективы» [1].
Основные понятия. Принцип работы MVC (model view controller).
MVC — это широко используемая техника разработки. Идея MVC заключается в разделении динамических приложений (как веб-приложений, так и других) на составляющие (модель — представление — контроллер). Это означает, что приложение делится на модель, управляющую данными, представления, определяющее, как будут отображаться данные, и контроллер, осуществляющий посреднические функции между первыми двумя уровнями и дающий пользователю возможность запрашивать данные и управлять ими.
Разделение приложения таким способом обеспечивает необходимую гибкость и позволяет многократно использовать один и тот же программный код. Например, существует модуль, способный отображать числовые данные в графическом виде, — этот модуль можно использовать для различных наборов данных при условии наличия связующего звена между модулем и данными.
На сегодня это самая популярная парадигма программирования, которая используется при веб-разработке. Сервис, представленный в данной работе, также использует MVC.
Рис. 1. MVC
Ключевые принципы MVC:
- Модели (models) — ответственны за данные приложения и доступ к базе данных.
- Контроллеры (controllers) — отвечают за взаимодействие пользователя с системой. При необходимости контроллеры получают данные из моделей.
- Представления (views) — выводят данные, полученные от контроллера.
Прямой связи между представлениями и моделями не существует. Наглядная демонстрация принципа работы MVC представлена в качестве блок схемы на рис. 2.
Рис. 2. Взаимодействие в MVC
Рассмотрим представленный принцип на примере данной работы. В качестве данных (models) у нас используется база аварий. В качестве контроллера используются методы и алгоритмы, представленные в данной работе, для запроса и обработки данных. В качестве визуальной составляющей (view) используется страница сайта. Таким образом, изначально пользователь видит страницу сайта, затем отправляет запрос с информацией, откуда и куда он хочет поехать. Контроллер получает эти данные, применяя к ним свои прописанные методы, происходит первый этап обработки, затем запрашивает из базы (models) аварии по маршруту, после получения аварий происходит вторая стадия обработки данных. Затем составляется ответ и отправляется во view и пользователь видит маршрут и информацию о нем.
Сбор данных.
Данные об авариях на дорогах Санкт-Петербурга были собраны с официального сайта ГИБДД. С сайта информация об авариях качается в формате xls файлов. Далее программа разбирает скаченный файл и забирает оттуда нужную информацию. Была предпринята попытка полностью автоматизировать процесс обновления базы, но удалось реализовать только некоторые этапы автоматизации:
− Автоматически происходит разбор скаченного файла;
− Автоматически происходит обновление базы с добавлением в нее новых аварий.
Не удалось реализовать автоматическое скачивание файлов с сайта ГИБДД, так как на сайте стоит ограничение по количеству запросов в минуту с одного компьютера. И в случае превышения лимита блокируется возможность обращаться на сайт. В данный момент на сайте висит объявление о том, что вскоре будет разработан GIBDD API, с помощью которого можно будет получать информацию об авариях в автоматизированном режиме. И тем самым можно будет расширить сервис по всем регионам России.
После сбора происходила обработка данных, и все данные были внесены в одну большую базу. Для хранения данных была выбрана база MySQL. О каждой аварии хранится следующая информация: универсальный номер (id) каждой аварии, день, в который произошла авария, район аварии, вид ДТП, точный адрес ближайшего дома, рядом с которым произошла авария. Фрагмент собранной базы представлен на рис. 3.
Рис. 3. База аварий
Для хранения информации о маршруте была создана дополнительная база, куда записывается информация о каждом построенном маршруте пользователя, а именно: точка отправления, точка прибытия, общая длина маршрута, аварийность маршрута, приходящаяся на 1 км, и выборочное среднеквадратическое отклонение (риск маршрута).
Построение маршрута.
При построении маршрута пользователь видит только карту, на которой изображен маршрут. Программа в этот момент получает все координаты перекрестков, через которые проедет пользователь, и делит маршрут на отрезки от перекрестка до перекрестка. Далее попарно берутся координаты перекрестков, которые являются концами отрезков, и строится прямоугольник следующего вида (см. рис. 4):
Рис. 4. Подсчет аварий
Далее из базы запрашиваются все аварии, которые произошли на улице 
в данный день недели. И уже из этих аварий выбираются только те, которые попадают в прямоугольник, представленный на рис. 4. Алгоритм проверки следующий:
- Берутся адреса, запрошенных ранее аварий (которые произошли в данный день недели и на улице, которой принадлежит конкретный отрезок);
- С помощью службы геокодирования эти адреса переводятся в координаты;
- На этом этапе происходит проверка, проверяем, какие из координат входят в прямоугольник, который показан на рис. 4.
Разберем третий этап подробнее. Пусть у точки 
координаты
, у точки 
. И есть некоторая авария - назовем ее 
, Она произошла в данный день недели на улице, которой принадлежит наш отрезок 
. Далее происходит проверка на истинность следующих неравенств:
Если оба неравенства выполняются, то координаты входят в построенный прямоугольник, и мы относим эту аварию к отрезку . Затем берем следующую аварию и также проверяем.
Такая процедура проделывается для каждого отрезка. В результате получаем количество аварий на каждом отрезке в определенный день недели.
Взаимодействие сGoogle API.
API (application programming interface) — набор готовых классов, процедур, функций, структур и констант, предоставляемых приложением (библиотекой, сервисом) или операционной системой для использования во внешних программных продуктах. Используется программистами при написании всевозможных приложений.
Формат взаимодействия с Google API может быть двух видов: json запрос или xml запрос. В данной работе будем использовать json формат взаимодействия, так как он работает быстрее. Запрос отправляемый на сервер Google API выглядит следующим образом: https://maps.googleapis.com/maps/api/directions/json?origin=A&destination=B&key=you-api-key
Где вместо A вписывается адрес, откуда нужно строить маршрут, вместо В — адрес конечной точки маршрута. Параметр key — это индивидуальный ключ, который выдается сервисом разработчику для взаимодействия с API. В данной работе также используется параметр mode, который отвечает за построение маршрута для пешехода или водителя.
В ответ на запрос от сервера приходит следующая информация о маршруте: общая длинна пути, предполагаемое время в пути, далее идёт пошаговая инструкция с координатами перекрестков, с которых нужно будет совершить поворот, информации о длине каждого участка дороги, по которому проедет пользователь.
На рис. 5 для наглядности приведен фрагмент ответа сервера на запрос, где вместо A было вписано «Санкт-Петербург метро Нарвская», а в качестве конечной точки маршрута B — «Санкт-Петербург метро Елизаровская»
Рис. 5. Json ответ
Вывод.
Таким образом, анализируя каждый построенный маршрут пользователя, мы сообщаем ему не только стандартную информацию, но и информируем его об опасности построенного маршрута, выявляя опасные участки дорог и предлагая ему по возможности их объехать.
Хорошим результатом будет, если данные исследования, методы и реализованные технологии будут использоваться в дальнейшем для обеспечения безопасности на дорогах.
Литература:
- Технические науки: проблемы и перспективы: материалы IV междунар. науч. конф. (г. Санкт-Петербург, июль 2016 г.). — СПб.: Свое издательство, 2016.
- Сервис представленный в данной работе. http://avariyamnet.ru.
