В данной статье описывается создание web-сервиса для проверки уровня безопасности построенного маршрута. Метод анализа построенного маршрута для водителя и пешехода представлен на конференции «Технические науки: проблемы и перспективы» [1].

Основные понятия. Принцип работы MVC (model view controller).

MVC — это широко используемая техника разработки. Идея MVC заключается в разделении динамических приложений (как веб-приложений, так и других) на составляющие (модель — представление — контроллер). Это означает, что приложение делится на модель, управляющую данными, представления, определяющее, как будут отображаться данные, и контроллер, осуществляющий посреднические функции между первыми двумя уровнями и дающий пользователю возможность запрашивать данные и управлять ими.

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

На сегодня это самая популярная парадигма программирования, которая используется при веб-разработке. Сервис, представленный в данной работе, также использует MVC.

Рис. 1. MVC

Ключевые принципы MVC:

1. Модели (models) — ответственны за данные приложения и доступ к базе данных.
2. Контроллеры (controllers) — отвечают за взаимодействие пользователя с системой. При необходимости контроллеры получают данные из моделей.
3. Представления (views) — выводят данные, полученные от контроллера.

Прямой связи между представлениями и моделями не существует. Наглядная демонстрация принципа работы MVC представлена в качестве блок схемы на рис. 2.

Рис. 2. Взаимодействие в MVC

Рассмотрим представленный принцип на примере данной работы. В качестве данных (models) у нас используется база аварий. В качестве контроллера используются методы и алгоритмы, представленные в данной работе, для запроса и обработки данных. В качестве визуальной составляющей (view) используется страница сайта. Таким образом, изначально пользователь видит страницу сайта, затем отправляет запрос с информацией, откуда и куда он хочет поехать. Контроллер получает эти данные, применяя к ним свои прописанные методы, происходит первый этап обработки, затем запрашивает из базы (models) аварии по маршруту, после получения аварий происходит вторая стадия обработки данных. Затем составляется ответ и отправляется во view и пользователь видит маршрут и информацию о нем.

Сбор данных.

Данные об авариях на дорогах Санкт-Петербурга были собраны с официального сайта ГИБДД. С сайта информация об авариях качается в формате xls файлов. Далее программа разбирает скаченный файл и забирает оттуда нужную информацию. Была предпринята попытка полностью автоматизировать процесс обновления базы, но удалось реализовать только некоторые этапы автоматизации:

− Автоматически происходит разбор скаченного файла;

− Автоматически происходит обновление базы с добавлением в нее новых аварий.

Не удалось реализовать автоматическое скачивание файлов с сайта ГИБДД, так как на сайте стоит ограничение по количеству запросов в минуту с одного компьютера. И в случае превышения лимита блокируется возможность обращаться на сайт. В данный момент на сайте висит объявление о том, что вскоре будет разработан GIBDD API, с помощью которого можно будет получать информацию об авариях в автоматизированном режиме. И тем самым можно будет расширить сервис по всем регионам России.

После сбора происходила обработка данных, и все данные были внесены в одну большую базу. Для хранения данных была выбрана база MySQL. О каждой аварии хранится следующая информация: универсальный номер (id) каждой аварии, день, в который произошла авария, район аварии, вид ДТП, точный адрес ближайшего дома, рядом с которым произошла авария. Фрагмент собранной базы представлен на рис. 3.

Рис. 3. База аварий

Для хранения информации о маршруте была создана дополнительная база, куда записывается информация о каждом построенном маршруте пользователя, а именно: точка отправления, точка прибытия, общая длина маршрута, аварийность маршрута, приходящаяся на 1 км, и выборочное среднеквадратическое отклонение (риск маршрута).

Построение маршрута.

При построении маршрута пользователь видит только карту, на которой изображен маршрут. Программа в этот момент получает все координаты перекрестков, через которые проедет пользователь, и делит маршрут на отрезки от перекрестка до перекрестка. Далее попарно берутся координаты перекрестков, которые являются концами отрезков, и строится прямоугольник следующего вида (см. рис. 4):

Рис. 4. Подсчет аварий

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

1. Берутся адреса, запрошенных ранее аварий (которые произошли в данный день недели и на улице, которой принадлежит конкретный отрезок);
2. С помощью службы геокодирования эти адреса переводятся в координаты;
3. На этом этапе происходит проверка, проверяем, какие из координат входят в прямоугольник, который показан на рис. 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 ответ

Вывод.

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

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

Литература:

1. Технические науки: проблемы и перспективы: материалы IV междунар. науч. конф. (г. Санкт-Петербург, июль 2016 г.). — СПб.: Свое издательство, 2016.
2. Сервис представленный в данной работе. http://avariyamnet.ru.