Индекс твоего города — Карты на стол

Предоставлен доступ к исходному коду для city-indexes.online. Собраны ответы на частые вопрос в одном месте.

Все статьи: Один, Два, Три.

Обновлений для пользователя немного — добавлены города Вологда, Новороссийск, Ульяновск, Париж и Ницца (не спрашивайте почему такой странный список — так просили в комментариях).

Основное — это открытый код для расчетов и самого сайта — City Indexes — GitLab. Базовые шаги по процессу подготовки данных расписаны в README — описание рассчитано на опытных разработчиков (не разъясняются типовые подходы и конфигурации), но если у кого-то возникают вопросы пишите в комментариях или в самом репозитории (через issues).

Сам сайт переехал с Yandex Cloud (дорого для нормальной конфигурации и переодически странные outages) на личное железо и «спрятался» за Cloudflare.

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

• «Идея очень похожа на описанное еще где-либо» — Я не претендую на оригинальность идеи. Были заготовки кода, которые собрались просто в одну систему и выложили, если кому-то будет полезно. Патентовать или зарабатывать именно на этой системе не собираюсь. Если кому-то интересен мой опыт — можно написать в личку и обсудить сотрудничество.

• «Почему белый экран» — Это связано с очень долгим ответом сервера, что вызвано большим наплывом пользователей. Все-таки это не коммерческий сайт и ему не уделяется столько времени/денег чтобы делать скалирование или управление нагрузкой. Так же возможно кто-то краулит сайт — если вам нужны данные в сыром формате, напишите в личку — вышлю/выложу.

• «Почему не работает поиск» — Для поиска (геокодирования) используется внешний сервис Stadia Maps (пока что) и бесплатные лимиты, как правило под конец месяца они выбраны, и надо ждать первого числа, чтобы опять работал поиск.

• «Какой-то странный индекс для плотности застройки» — С индексами интуитивно каждый по разному понимает (смотри описание в Помощи — знак вопроса справа-внизу в меню) — с плотностью застройки у всех возникают проблемы. Значение индекса 0 (на карте красное — плохо) говорит о высокой плотность застройки, и соответственно если застройка не плотная, то значение ближе к зеленому (зеленый — хорошо). А для доступности транспорта говорит именно о доступности (чем выше индекс, тем ближе к зеленому), но и тут «проблема» — мы не знаем куда конкретно хочет ездить человек, индекс это просто наличие остановок, кол-ва маршрутов на них и длины этих маршрутов, а доедем ли до вокзала, например, этого индекс не учитывает.

• «Объект закрыт на ремонт или больше не функционирует, но очень похоже что попадает в индекс» — Если какой-то из объектов на ремонте — то это не отражается в индексе (в смысле что индекс считается по нему все-равно). Такая информация редко есть в OSM. Так же совсем новых объектов может и не быть, или объекты изменили назначение — в индексе это отразиться только при следующей загрузке (раз в месяц) при условии внесения этих данных в OSM.

• «Не все парки попадают в индекс» — Как правило это означает, что в OSM это либо не общественные парки (protected, restricted access), либо помечены как лес/деревья. Я осознанно не включаю леса в индекс (скопление «деревьев» в городе будет учтено как парк, но так же в расчет берется и его площадь — влияние может быть минимальным в этом случае на индекс) — прогулка в парке и в лесу все-таки разные вещи.

• «Соседние гексагоны имеют значительно отличающиеся значения индекса» — Связано с тем, что нормализуется по всему городу (и где-то есть дома у которых намного ближе детские сады, например) и локально могут быть такие данные. Если хотим для небольшого района посмотреть распределение — выбираем только его (тул справа экрана — Polygons tool) либо выбираем индекс в меню «Для всего города». В таком случае будет более наглядная картина. Так же более «правильно» смотреть индексы по изохронам — особенно для областей разделенных преградами — вода, автострады и прочее. Изодраны — это реальные расстояния для пешеходов (если надо перейти мост, например).

• «Нет данных в пограничных районах города» — Индекс строится строго по границе города (административной), которая внесена в OSM. Поэтому, если парк за границей города, то он не будет учтен для застройки на границе города.

• «Добавить бы метеорологические данные (чистота воздуха, например)» — Пока расчет индексов построен на offline обработке, добавление real-time данных потребует чуть другого подхода. Да и источников достоверных данных (для погоже воздуха) практически нет, а добавление только погоды не совсем уместно — все-таки плотность застройки/наличие парков немного более статична и какие там дуют ветра, не особо важно. Когда выбор происходит на уровне сторон света — тогда уже такими ресурсами, как мой, уже не пользуются (лучше прийти ногами и все увидеть самому).

• «Для чего необходимо с помощью подхода IQR заменять максимальные значения индексов перед их сложением в общий индекс» — Это делается не перед сложением, а перед нормализацией каждого отдельного индекса. Избавляется от «перекошенности» гистограммы — убираем максимумы и минимумы — иначе карта либо вся зелена, либо вся красная.

• «С чем связан выбор диапазона значений весов от -5 до 5″ — Основная идея это возможность «переворачивать» индекс (используя минусовые значения коэффициента). «5» — так как данные нельзя назвать очень точными на карте, то и иметь коэффициент 100 например не имеет смысла. Первоначально была идея вообще «важно/не очень важно/пофиг» градацию использовать (может на это и перейдет).

• «Какая техническая составляющая процесса перерасчёта показателей (при выборе разных весов)» — Сами индексы хранятся в PostgreSQL — таблица с h3 полигоном и набором колонок smallint для каждого доступного индекса по отдельности. Martin вызывает функцию в PostgreSQL, которая на основе параметров (зум, город и полигон) делает выборку, агрегирует (по h3 level 9 or level 10) в общий индекс с учетом весов, нормализует и упаковывает в тайл исходные индексы и общий индекс. Кэширование стоит на уровне nginx — что бы не пересчитывать одно и тоже каждый раз.

Дальнейшие планы

Пока нет. Все что обещал — сделано. Если есть вопросы или нужна помощь в чем-то похожем (гвоинформатика) — обращайтесь.