stepan-anokhin / spb-histmap Goto Github PK

Зависит от #2 и #6

Контекст

Как пользователь, я хочу фильтровать данные, отображаемые на карте. Как минимум я хочу искать события по адресу, и отсеивать их по времени (от и до). Фильтры данных должны отображаться на сайдбаре. Сайдбар должен быть закрываемым, чтобы позволять работать только с картой, когда он не нужен.

Задача

Реализовать отображение событий в соответствии с фильтрами на сайдбаре:

• Данные на карте должны отображаться в соответствии с фильтрами, установленными пользователем на сайдбаре
• Фильтры автоматически применяются после таймаута (~ 3 секунд).
• Пока пользователь совершает действия с фильтрами чаще, чем по таймауту, фильтры не применяются.

Контекст

Связано с #11

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

Задача

1. Расширить модель для того, чтобы можно было классифицировать типы событий
2. Ассоциировать разные иконки с разными типами событий
3. Добавить фильтр на тип события.

Контекст

Поскольку реальные данные временно недоступны (предположительно до, февраля 2022) весь функционал придется отрабатывать на фейковых данных.

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

Задача

Автоматизировать генерацию фейковых данных:

1. Написать скрипт, генерирующих фейковые данные.
2. Скрипт должен принимать количество событий в качестве параметра.
3. Скрипт должен запускаться через npm run и не требовать дополнительных действий после запуска.
4. Данные должны иметь тот же формат, который будут иметь реальные данные
5. Фейковые данные должны иметь реальные адреса. Исторические адреса для простоты могут совпадать с современными (по крайней мере, пока не реализована конвертация между историческими и новыми адресами)

Ресурсы

• Nominatim - сервис по конвертации адресов в координаты
• BBBike - сервис для скачивания данных OpenStreetMap. Может пригодиться для того, чтобы достать все реальные адреса Питера.

Зависит от #10

Контекст

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

Задача

Интегрировать кастомные иконки в приложение.

Ресурсы

• custom marker icon with react-leaflet - вопрос на StackOverflow
• Markers With Custom Icons - туториал по добавлению кастомных иконок маркеров в leaflet.js

Если не срастётся с привлечением художников, можно использовать вот эти бесплатные иконки:

1. Bomb
2. Fire
3. Bomb Vertical

Контекст

Как разработчик я хочу всегда видеть актуальную версию приложения, задеплоиную на https://stepan-anokhin.github.io/spb-histmap/

Как разработчик я также хочу избежать рутинных операция по деплою.

Задача

Вливание изменение в ветку master должно автоматчески деплоить обновленную версию на https://stepan-anokhin.github.io/spb-histmap/.

Ссылки

https://github.community/t/triggering-by-other-repository/16163

Контекст

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

1. Исходные данные

Исходные полигоны и линии, скорее всего, будут рисоваться руками в этом редакторе: http://share.mapbbcode.org. Нарисованные элементы затем можно экспортировать в разные форматы. На вскидку, самым удобным для парсинга кажется GeoJSON

2. Ображения результата

Для рисования полигонов и линий на карте у react-leaflet есть вот такое API: https://react-leaflet.js.org/docs/example-vector-layers/

Задача

Надо отработать процесс отображения того, что экспортнула рисовалка (1) (например, файла в формате GeoJSON), с помощью react-leaflet-овского API (2). Все промежуточные манипуляции должны быть по максимуму автоматизированы, чтобы имея на руках файл, экспортнутый рисовалкой, можно было тривиально добавить его в приложение.

Другими словами, хочется следующее:

1. Если у меня есть файлик с GeoJson, мне должно быть элементарно просто добавить соответствующие элементы (полигоны и линии) на карту приложения, в идеале не особо вникая, что там внутри содержится.
2. Если у меня на карте отображается какой-то элемент (полигон или линия), мне должно быть легко удалить его из проекта, заменить или отредактировать в карте-рисовалке.

В общем эти операции надо отработать и по максимуму автоматизировать.

Как может выглядеть процесс

В идеале это может выглядеть так:

Чтобы добавить элемент, кидаешь исходные geo-json файлы с осмысленными именами в какую-нибудь папку проекта, потом запускаешь скрипт (скажем, npm run generate-elements), который что-то делает (например генерирует typescript-файлы). Всё, после билда соответствующие элементы появляются на карте.

Чтобы удалить элемент, удаляешь соответствующий geo-json файл, затем снова запускаешь npm-run generate-elements, всё элемент пропал из приложения.

Чтобы редактировать: берёшь geo-json файл из проекта, импортишь его в рисовалку, редактируешь, как тебе надо, затем экспортишь обратно, пихаешь обновленный файл в исходное место в проекте, запускаешь скрипт, вуа-ля элемент обновился.

Возможно удастся обойтись вообще без дополнительного скрипта, если какой-нибудь модуль просто будет выгребать данные прямо из json-файлов. Тогда чтобы добавить элемент, скажем надо его кинуть в папку и импортнуть в нужном месте.

Пример экспорта геодаты:
test-line.zip

Контекст

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

Задача

Реализовать отображение основных деталей события в popup-е при нажатии на маркер:

• Дату события
• Адрес события
• Тип события
• Дополнительное описание.

Как пользователь, я хочу видеть в приложении свое местоположение.

Контекст

Как пользователь, который впервые открыл приложение, я хочу быстро разобраться в контексте: что это и почему может быть мне интересно.

Задача

Реализовать Landing-page со следующим содержимым:

• Описание приложение и смысла отображаемых данных
• Ссылка на оригинальную книгу Баира Иринчеева
• Крупная кнопка, открывающая карту.

Контекст

Текущий Подход

В рамках текущего подхода мы поступаем следующим образом:

1. Мы конвертируем все исходные данные в TypeScript-модуль, содержащий массив событий. Каждое событие представлено литералом объекта.
2. Код приложения просто импортирует данные из сгенерированного модуля с данными.
3. Мы используем WebPack чтобы скомпоновать весь имеющийся код в один js-файл main.bundle.js. Этот бандл грузится браузером, когда пользователь открывает страницу с приложением.

Мотивацией такого подхода является отсутствие необходимости иметь бэкенд. Любого http-сервера, способного отдвать статические файлы (index.html, main.bundle.js и иконки) будет достаточно. Поэтому мы например можем разместить пилотную версию приложения на github-pages и не платить не копейки.

Проблемы

Производительность

Текущий подход имеет ряд серьёзных проблем:

1. Он совершенно не масштабируется:
   • Мы хотим отображать потенциально десятки тысяч событий только для одного Ленинграда. Бандл с данными становится просто огромным. Он сразу жрёт кучу памяти в браузере и очень долго грузится.
   • Если мы захотим охватить другие сражения (не только блокаду Ленинграда), объем данных возрастёт кратно и нам потребуется подгружать даже то, что мы в данный момент не собираемся отображать. Это безумие. Текущий подход просто закрывает нам любую возможность развивать приложение в этом направлении.
2. Мы используем динамическую кластеризацию маркеров. Нет уверенности, что алгоритм будет работать достаточно быстро, когда мы отображаем тысячи или десятки тысяч событий (это, вообще говоря, еще надо проверить. Может быть, для нашей задачи динамической кластеризации будет достаточно).

Как Отображать Неполные Данные

Надо также понять, как отображать неполные исходные данные. Часть исходных данных изначально представлена в виде групп событий (например, количество прилётов в такой-то район на такую-то неделю). Часть - в виде индивидуальных событий (по большому счёту - отедельных рапортов). Надо решить как отображать группы событий, если мы используем одновременно и алгоритм динамической клстеризации.

TypeScript Удорожает Реализацию Препроцессинга

Еще одной проблемой является то, что конвертацию исходных данных в ts-модуль мы также реализуем на typescript. При всей прелести системы типов, этот язык не совсем подходит для парсинга файлов и преобразования данных. На практике асинхронный стиль удорожает реализацию без какой-либо надобности: разработчики по сути тратят дополнительные усилия на описание алгоритма в рамках вычслительной модели, которая вообще говоря создана для ускорения IO-intensive кода, но скорость препроцессинга совершенно не влияет на скорость самого приложения. Было бы неплохо реализовать препроцессинг, например, на python, особенно учитывая огромное количество библиотек для работы с данными.

Общая Идея Решения

Этот раздел не дописан

В общих чертах: мы стремимся к content-oriented архитектуре. Есть движок (пока что это только фронт, выполняющийся на клиенте) для отображения, и есть content. Клиент динамически подгружает детали того, что надо отображать. Клиент должен иметь возможность грузить данные кусками (надо понять как это делать: есть несколько вариантов, но для каждого я вижу некоторые сложности в реализации, которые пока не придумал как решить). Для препроцессинга данных надо создать полноценный пайплайн на питоне. Предлагаю использовать luigi для организации графа задач и инкрементного ленивого выполнения (аналог Make, по сути, но даже сложно преувеличить насколько лучше). Пайплайн должен брать исходные данные и генерировать набор статических файлов, которые будет динамически подгружать клиент (пока что мы не отказываемся от API-less подхода). Пайплайн будет выполнять статические преобразования, типа поиска координат по адресу дома и т.п. и возможно более умной обработки (ститическая кластеризация? Раскладывание событий по тайлам?). Изменения на фронте: нужно написать интерфейс клиента, который будет грузить нужные данные динамически. Текущая реализация этого интерфейса будет грузить статические файлы по URL, а в будущем он может обращаться по rest api к серверу, если мы всё-таки добавим умный бэк, причем это не должно потребовать изменений в остальном коде. Частичная загрузка данных усложняет фильтрацию. Надо понять, как это преодолеть.

Надо теперь превратить этот поток сознания в нормальное описание и добавить сюда набор подзадач

Задача

• Извлечь данные по отдельным событиям из книги в csv файл
• Подготовить csv-файл с переименованием улиц
• Разобраться с упраздненными улицами.

Формат таблицы для одиночных событий

CSV-файл. Разделитель - запятая (,). Если событие описано для улицы, номер дома и тип дома просто оставляем пустым.

• Дата - в формате ГГГГ-ДД-ММ
• Улица - историческое название улицы
• Дом - исторический номер дома
• ТипДома - тип учреждения, тип дом (больница, жилой дом, и т.п.)
• Количество - количество снарядов
• Тип - тип снаряда. Возможные значения:
  • З - зажигательные бомбы
  • Ф - фугасный снаряд
  • А - артиллерийский
• Описание - словесное описание

Формат таблицы для переименований улиц

CSV-файл. Разделитель - запятая (,).

• Исторический - историческое название улицы
• Тип - улица, переулок, проспект, площадь, набережная, мост
• Современный - современное название улицы
• Тип - улица, переулок, проспект, площадь, набережная, мост, адрес (если улица ликвидирована)

Возможно понадобится: Формат таблицы для групп событий

• Дата - в формате ГГГГ-ДД-ММ
• Район - историческое название районов
• Количество - количество снарядов
• КоличествоДомов - количество поврежденных/разрушенных домов
• Тип - З,Ф или А
• Описание - словесное описание

Контекст

Как пользователь, я хочу видеть, как события происходили в динамике. Для этого необходимо реализовать возможность интерактивно менять временное окно и смотреть, как данные динамически меняются на карте.

Задача

Добавить слайдер, позволяющий двигать временное окно, по которому фильтруются события:

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

Ресурсы

• MUI Slider Component - можно использовать стандартный MUI-шный слайдер.

Контекст

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

Задача

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

Как пользователь, я хочу иметь возможность установить приложение из google play и appstore, а также запускать приложение под windows и linux не устанавливаю никаких доплнительных компонентов. Для этого нужны сборки под соответствующую ОС.

Контекст

eslint выдает следующие ворнинги:

> [email protected] lint
> eslint src


/home/stepan/WebstormProjects/spb-gpw2-histmap/src/components/HistMap/HistMap.tsx
  22:39  warning  Unexpected any. Specify a different type  @typescript-eslint/no-explicit-any
  36:37  warning  Unexpected any. Specify a different type  @typescript-eslint/no-explicit-any

/home/stepan/WebstormProjects/spb-gpw2-histmap/src/processing/script-utils.ts
  168:44  warning  Unexpected any. Specify a different type  @typescript-eslint/no-explicit-any

✖ 3 problems (0 errors, 3 warnings)

Задача

1. Исправить проблемы, выявленные eslint
2. Изменить настройки eslint, чтобы билд падал при любом количестве ворнингов > 0
3. Изменить настройки TypeScript, чтобы проверки были более строгими (например, запретить implicit/explicit any)
4. Применить стили prettier на *.geojson-файлы

Контекст

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

Как пользователь я хочу иметь возможность выбирать, какие дополнительные данные отображаются на карте: линии фронта, направления ударов, коммуникации.

Как программист я хочу иметь возможность подстраивать поведение программы (например текст описания) в зависимости от типа данных.

Задача

1. Определить следующие типы дополнительных элементов на карте:
   1. "Группировка войск" - территория, контролируемая определенной группировкой войск
   2. "Линия фронта" - разграничительная линия
   3. "Линия коммуникаций" - линия по которой осуществлялась перевозка людей, припасов, каких бы то ни было ресурсов или передача информации
   4. "Направления ударов" - линия обозначающая направления войсковых операций
2. Описание элемента во всплывашке должно учитывать тип элемента
3. Сайдбар должен позволять выбирать, какие типы элементов отображаются

Контекст

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

Текущий внешний вид:

Предпочтительный внешний вид:

Задача

Поменять внешний вид scrollbar-а на более предпочтительный.

Контекст

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

Задача

Реализовать e2e тесты (желательно с помощью Cypress), проверяющие основные сценарии использования:

1. Отображение маркеров на карте
2. Открытие/закрытие сайдбара
3. Фильтрация событий в соответствии с вводом пользователя.
4. Опционально: отображение popup-а при нажатии на маркер.

Контекст

На сайте http://retromap.ru в свободном доступе находятся тайлы исторических карт РККА на 1941 год.

Как пользователь я хочу видеть исторические карты Ленинграда, относящиеся к периоду блокады.

Задача

1. Реализовать отображение исторических карт, с использованием тайлов доступных на http://retromap.ru
2. Реализовать возможность переключения между современной картой и исторической картой.
3. Добавить упоминание http://retromap.ru в описание проекта и в само приложение.

Добавить sidebar с фильтрами

Как пользователь, я хочу иметь возможность видеть в приложении попадания авиабомб и арт-снарядов в радиусе 200 метров от моего местоположения.

Контекст

Кроме артиллерийских и авиа-ударов мы отображаем также и дополнительные элементы - позиции войск, линии фронта и прочее (содержимое папки frontlines)

Как пользователь я хочу по цвету обозначений видеть с какой воюющей стороной ассоциированы те или иные данные (позиции войск, направления атак и т.п.)

Как пользователь я хочу иметь возможность фильтровать элементы карты по тому, с какой воюющей стороной они ассоциированы.

Задача

1. Реализовать ассоциацию дополнительных данных с той или иной воюющей стороной (РККА, Вермахт)
2. Реализовать фильтрацию дополнительных элементов на карте в зависимости от воюющей стороны.
3. Рассмотреть возможность окрашивания элемента в зависимости от воюющей стороны.

Контекст

Как пользователь, я хочу фильтровать данные, отображаемые на карте. Как минимум я хочу искать события по адресу, и отсеивать их по времени (от и до). Фильтры данных должны отображаться на сайдбаре. Сайдбар должен быть закрываемым, чтобы позволять работать только с картой, когда он не нужен.

Задача

Необходимо реализовать внешний вид сайдбара:

1. Набросать первичный вариант того, как будет выглядеть сайдбар.
2. Убедиться, что значения по-умолчанию в фильтрах установлены верно + используется русская локаль для дат.
3. Сайдбар должен открываться по нажатию floating action button-а, закрываться по Esc или click-away на мобиле
4. Сайдбар должен отображаться нормально на компе и на мобиле
5. На компе должна быть возможность взаимодействовать с картой, когда сайдбар открыт.
6. У сайдбара должна быть кнопка для закрытия.

Собственно фильтрация в эту задачку не входит.

Мокет

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

Задача
На всплывающей подсказке должно отображаться:

• наименование
• период "с дд.мм.гггг" и "по дд.мм.ггг"
  на данный момент отображается так
  https://user-images.githubusercontent.com/10139360/149290438-238ff36e-e2cc-426e-b1fb-831579b9ce78.png

Используя
http://share.mapbbcode.org/ipnxg?editid=ucmpm
нарисовать и сэкспортировать линии размещения войск на период зимы 1941-1942 годов согласно карте:
https://xn--80ahclcogc6ci4h.xn--90anlfbebar6i.xn--p1ai/multimedia/photo/gallery.htm?id=1130@cmsPhotoGallery

Контекст

Для отображения альтернативных (исторических/современных) адресов во время фильтрации по улице/дому (#12) и при подготовке реальных данных (#13) а также при генерации реалистичных фейковых данных (#6) сильно пригодится возможность быстро отображать исторические адреса в современные и обратно.

Задача

Реализовать возможность конвертации исторического адреса (улица, номер дома) в современный и обратно.

Контекст

Реальные данные будут доступны ориентировочно после Февраля 2022, не раньше, чем выйдет книга Баира. Данные будут получены в формате, отличном от того, что используется в приложении.

Задача

Конвертировать реальные данные в формат, используемый приложением. По возможности автоматизировать этот процесс или отдельные его этапы.

Зависит от #16

Контекст

Как пользователь я хочу видеть альтернативный адрес, когда я осуществляю фильтрацию по улице номеру дома:

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

Задача

Отображать историческое название улицы и номер дома (если есть) на сайдбаре под группой фильтров по адресу:

• Отобразить альтернативный адрес на сайдбаре, когда пользователь задаёт фильтрацию по улице/номеру дома.
• Если пользователь фильтрует по историческому адресу - необходимо дополнительно отображать современный. И наоборот.