Автор: Хачатрян Альберт Гагикович

Рубрика: Информатика

Опубликовано в Молодой учёный №14 (118) июль-2 2016 г.

Дата публикации: 17.07.2016

Статья просмотрена: 20 раз

Библиографическое описание:

Хачатрян А. Г. Реализация сервиса для проверки уровня безопасности построенного маршрута // Молодой ученый. — 2016. — №14. — С. 102-105.



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

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

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

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

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

/Users/ht_albert/Desktop/Диплом (Альберт Хачатрян)/img/mvc.png

Рис. 1. MVC

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

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

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

/Users/ht_albert/Desktop/Диплом (Альберт Хачатрян)/img/mvc2.png

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

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

Сбор данных.

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

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

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

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

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

/Users/ht_albert/Desktop/Диплом (Альберт Хачатрян)/img/table.png

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

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

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

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

/Users/ht_albert/Desktop/Диплом (Альберт Хачатрян)/img/avarii.png

Рис. 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 — «Санкт-Петербург метро Елизаровская»

/Users/ht_albert/Desktop/Диплом (Альберт Хачатрян)/img/json-answer.png

Рис. 5. Json ответ

Вывод.

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

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

Литература:

  1. Технические науки: проблемы и перспективы: материалы IV междунар. науч. конф. (г. Санкт-Петербург, июль 2016 г.). — СПб.: Свое издательство, 2016.
  2. Сервис представленный в данной работе. http://avariyamnet.ru.
Основные термины (генерируются автоматически): конечной точки маршрута, проверки уровня безопасности, координаты перекрестков, построении маршрута пользователь, общая длина маршрута, Google API, Построение маршрута, построение маршрута, аварийность маршрута, риск маршрута, сайта ГИБДД, нее новых аварий, следующая информация, обработки данных, база аварий, «Санкт-Петербург метро, Взаимодействие сgoogle api, json формат взаимодействия, прямоугольник следующего вида, База аварий.

Обсуждение

Социальные комментарии Cackle
Задать вопрос