Как сформировать технологический стек для веб-приложения с геоинформационной системой отслеживания грузового транспорта?

Question

[Neshvi]

Добрый день!
Я магистрант и пишу диплом. Нуждаюсь в помощи опытных специалистов:
Проект - геоинформационная система для отслеживания грузового транспорта.
Собираюсь реализовывать веб-приложение для закрытого круга пользователей (до 100 человек), то есть масштабируемость не так важна.
Хотелось бы найти такие решения в комбинации фреймворков, баз данных, чтобы достаточно просто описать и собрать проект для диплома. Приоритетный язык Python, понимаю что одним языком не ограничится)
Помогите собрать простой и работающий стек для моей задачи. Если что не описал или недостаточно погрузил в суть, то прошу прощения и велком в комменты, дополню вводными данными.

Comments

[Everything_is_not_so_bad]

А какая-либо подготовительная работа проделана до сих пор? Какие-то попытки были? Какие именно?

[Maksim B]

Вы просто веб-приложение с картой и рандомными маркерами на ней хотите создать?

[Neshvi]

Maksim B, примерно так как вы сказали - карта будет подключаться по апи, маркеры будут подтягивать данные с глонасс-трекеров. Также хотел как дополнение сделать небольшую аналитическую систему по полученным данным с трекеров

[Neshvi]

Everything_is_not_so_bad, есть концепт со схожим функционалом (https://login.avantern.ru/ - здесь можно зайти под демо логином и функционал отобразится). Я могу сам собрать стек, однако это будет сборка не на основе опыта, а на основе данных из открытых источников. Собирался использовать в качестве БД PostgreSQL или MySQL, а вот с выбором фреймворков и других компонентов возникают проблемы. Если вы имеете в виду подготовительные этапы в виде декомпозиции, ТЗ, то эти этапы собраны в упрощенном виде.

[maksam07]

вот с выбором фреймворков

Приоритетный язык Python

Вероятно django тебе должен подойти

Answer 1

[Артем Воронов]

Я собрал 3 подобных сервиса, как для Glonass/GPS, так и для AIS. В текущем решении 180 000 единиц транспорта отслеживается. Вот несколько базовых моментов из опыта:
1. Приборы отправляют данные на сервер сами, а не наоборот. Твоя задача принимать и быстро сохранять данные в бд. В какой - не важно. У меня хорошо работает связка из реляционной бд для оперативных данных типа текущего положения, nosql для архива.
2. Протоколов у трекеров огромный зоопарк, у каждого производителя свой. Не привязывай свою реализацию к конкретному протоколу. Сделай общий API для сохранения данных в базу, а затем уже подключай протоколы по мере необходимости.
3. Если тебе нужен геофенсинг, сразу закладывай event-driven архитектуру. Опять таки не важно какой ты возможешь брокер сообщений.
Все остальное вторично. Для отображения данных хоть на любом low-code забирай данные напрямую из оперативной базы и отображай на карте.

Answer 2

[Everything_is_not_so_bad]

Собирался использовать в качестве БД PostgreSQL или MySQL, а вот с выбором фреймворков и других компонентов возникают проблемы.

Вот и замечательно. Обычно берут одну из этих СУБД, чаще первую.

Если вы имеете в виду подготовительные этапы в виде декомпозиции, ТЗ, то эти этапы собраны в упрощенном виде.

Надо продолжать собирать требования и на их основе искать решения.

Нужно взяться за протоколы передачи данных.
Начиная с геолокации:
1. что за устройства устанавливаются на грузовой транспорт?
2. куда должны передаваться данные?
3. с какой частотой?
4. какие ограничения у этих устройств?
5. кто получатель геолокации? какие посредники при сборе геолокационных данных?
6. что происходит при получении геолокационных данных?

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

Фреймворки обычно не играют решающую роль в выборе тех. стека, если только не набран опыт в некоторых из них.