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

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.

Предоставлен доступ к исходному коду для 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 - что бы не пересчитывать одно и тоже каждый раз.

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

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

Источник: https://habr.com/ru/articles/856082/


Интересные статьи

Интересные статьи

Итак, к последней трети девятнадцатого века паровая энергия произвела революцию в горнодобывающей промышленности, производстве и транспортировке по суше, рекам и океанам. Казалось бы, этого уже было д...
Во второй части статьи про bitrix кластер мы будет рассматривать настройку percona xtradb cluster mysql 5.7, настройка арбитра, настройка удобного dashboard.Если вы пропустили предыдущие части: Первая...
Данная статья - это не научный прорыв, а лишь помощник быстрее понять как работает стандартный функционал в BitrixДавайте представим, что в разделе каталога у нас 150 запросов к БД. Вроде бы немного п...
Начало шаблона для быстрого заземления PHP-разработчиков в Go 15 лет мы делали бэкенд на PHP. И вот однажды было принято стратегическое решение: сначала переписать самые высоконагруженные ме...
В Челябинске проходят митапы системных администраторов Sysadminka, и на последнем из них я делал доклад о нашем решении для работы приложений на 1С-Битрикс в Kubernetes. Битрикс, Kubernetes, Сep...