Comments 31
А можно Краснодар добавить? Я думаю это будет востребовано.
Потыкал по центру Питера. Гексагон, в центре которого павильон метро, имеет меньший индекс доступности транспорта, чем гексагон, от которого до ближайшего метро километр. Вероятно, наземный и скоростной транспорт никак не различаются в алгоритме оценки, тогда как в действительности между ними огромная разница т.зр. реального удобства жителей.
Спасибо! Действительно упустил подземку. Изменю расчет - будет больше влияния от нее.
Вообще говоря, и в рамках наземного транспорта нужна бы дифференциация. Наличие рядом остановки автобуса, который ходит раз в 10 минут до поздней ночи и наличие рядом остановки автобуса, который ходит 3 раза в день, - с т.зр. транспортной доступности - две кардинально разные ситуации. Вот только эти данные уже из OSM не вытянуть...
Подземки на порядок влияние увеличено - должно быть получше теперь.
Если какой-то из садов/школ и прочих объектов на ремонте - то да, это не учитывается. Такая информация редко есть в OSM.
Так же совсем новых объектов может и не быть - задержка от месяца до 3 может оказаться пока внесут данные.
ИМХО.
Очень хорошая идея.
Уместно было бы добавить доступность медицинских учреждений: хотя бы поликлиник. Особенно детских.
Про доступность детских садов и школ. Правильно ли я понимаю, что транспортная или пешеходная доступность не учитывается ?
Пояснение к вопросу. Есть города, у которых по карте соответствующее образовательное учреждение на расстоянии "вытянутой руки", а на самом деле между ними может быть речушка, мостик через которую находится в паре километров.
Спасибо.
Медицина в планах на добавление. Там скорее всего будет больше "радиус достижимости" и не только поликлиники, но и более крупные медицинские учреждения.
Да, доступность пока просто радиусы (ну если раскрывать подноготную - путь по H3 гексагонам на самом деле). Случаи когда маршрут значительно больше, чем "прямая видимость", не доминирующие - поэтому пока на "радиусах". Расчет используя какую Valhalla значительно удлинит время подготовки данных, но в общем большого влияние не внесет. Оставляем это улучшение уже на "коммерческую" версию (если такая будет кому-то нужна).
Подготовить и открыть исходный код.
Ждём! Если добавить города, будет очень интересный сервис
Интересный проект, но все как обычно упирается в качество данных - даже для человейников сданных 10 лет назад плотность застройки 0, а с парковкой и доступностью все ок, хотя дело как раз наоборот + берег левый берег правый сильно влияет на путь)
С индексами просто интуитивно каждый по разному понимает - с плотностью застройки у всех возникают проблемы. Там в подписи с полю указано - что как раз 0 значение (на карте красное - типа плохо) говорит о высокой плотность застройки, и соответственно если застройка не плотная, то значение ближе к зеленому (типа зеленый хорошо).
Доступность транспорта говорит именно о доступности - мы же не знаем куда конкретно хочет ездить человек. Для построения изохрон есть другие сервисы, например https://commutetimemap.com/map. Но как идея иметь все в одном месте очень хорошая.
Ждём Белград и Нови-Сад
Возможно, это всего лишь совпадение, и я покажусь слишком придирчивым или тщеславным, но мне кажется, что ваш проект очень похож на мой, вышедший меньше месяца назад, и статья о котором также была опубликована на Хабре. Похож он, причём, основной идеей, а именно возможностью проставления коэффициентов, которую я прежде нигде не встречал. Но при этом вы даже не упомянули мою публикацию, хотя в закладках она у вас есть, а, следовательно, вы её читали.
Да, вы добавили предложение: «Никакой монетизации не предвидится, поэтому простите, если где-то забыта лицензия или упоминание кого-либо». Но в данном случае оно звучит в духе: «Кем вдохновился, рассказывать не буду. Ну, до тех пор, пока, вдруг, при попытках монетизировать не придётся». Причём речь идёт явно не о лицензии на данные или сервисы, ибо на сайте у вас указаны и OpenStreetMap, и MapLibre.
Я совершенно не против, если вам понравилась моя идея, и вы решили её масштабировать. Как-никак, я сам подробно расписал процесс создания своего проекта. Мне, к слову, понравилась ваша идея использовать слайдер для ограничения результатов по баллам. Просто мне кажется, что это некрасиво — так продолжать свежую, только что вышедшую идею и не упоминать её. Хоть и понимаю, что это вовсе не обязательно. Опять же повторюсь: возможно, это просто невероятное совпадение с разницей в 20 дней. Но даже если это и так, то очень странно, что вы не подметили его, хотя явно знали о нём. Моё сомнение по поводу этой версии усиливается ещё и тем, что в статье вы крайне мало рассказали о процессе создания проекта.
Закончив с этой, возможно, необъективной преамбулой, мне бы хотелось задать несколько вопросов по вашему проекту. Если вы не против, после прошлых слов, конечно.
Можете, пожалуйста, объяснить, для чего необходимо с помощью подхода IQR заменять максимальные значения индексов перед их сложением в общий индекс?
Выбор диапазона значений весов от -5 до 5 как-нибудь связан с необходимостью использовать межквартильный размах (IQR), или это исключительно вопрос восприятия?
Если не секрет, не могли бы вы рассказать немного о технической составляющей процесса перерасчёта показателей? Судя по параметрам запроса, я так понимаю, что данные изначально хранятся в векторных тайлах, которым передаются значения коэффициентов, и после эти тайлы пересчитываются и возвращаются обратно, верно? Если так, то для хранения, перерасчёта и обратной визуализации тайлов используется Martin, или какая-то из этих частей выполняется PostgreSQL? Ну, это если я в целом правильно понял логику работы.
Возможно, это всего лишь совпадение, и я покажусь слишком придирчивым или тщеславным, но мне кажется, что ваш проект очень похож на мой, вышедший меньше месяца назад, и статья о котором также была опубликована на Хабре.
Это не совпадение, ваша статья была триггером (очень фундаментальный труд я бы сказал - читал правда не каждое слово/параграф я, позже объясню почему) - достаточно давно лежал код, который делал очень похожее как вы описали. Еще в бытность мою работы в MapBox (если знаете таких - кто усиленно пользует и улучшает OSM), я занимался и дорогами (перенос знаков и дорожной разметки в карту), и трафиком - тот что красно/желто/зеленый на дорогах. Я много сталкивался с "качеством карт" - мы пытались строить различные метрики (и сравнивать c картами Google, Bing, Here) используя разные подходы (и просто считать какие-либо тэги, и прокладывать маршруты использую Valhalla, и сравнивать "визуально" растровые изображения слоев). На последнем месте работы вся система была построена вокруг Uber H3 геокодинга (агрегировали, нормализовали, предсказывали, искали схожесть по набору параметров). Поэтому детали в вашей статье меня не сильно интересовали (давно уже этот этап сравнения пройден), но саму идею ухватил и понял, что есть люди которые думают схоже. И чтобы не было потом вот таких претензий - привел в нормальный вид (как раз закончился очередной проект и было время) и выложил свой вариант реализации.
Похож он, причём, основной идеей, а именно возможностью проставления коэффициентов, которую я прежде нигде не встречал.
Вообще то "сложение" слоев используется часто для отображения геоинформации. Многие инструменты позволяют настраивать как эти слои складываются (additive/subtractive), с какой прозрачностью. Что тут нового и уникального чтобы претендовать на авторство - не совсем понятно.
Но при этом вы даже не упомянули мою публикацию, хотя в закладках она у вас есть, а, следовательно, вы её читали.
Да, вы добавили предложение: «Никакой монетизации не предвидится, поэтому простите, если где-то забыта лицензия или упоминание кого-либо». Но в данном случае оно звучит в духе: «Кем вдохновился, рассказывать не буду. Ну, до тех пор, пока, вдруг, при попытках монетизировать не придётся». Причём речь идёт явно не о лицензии на данные или сервисы, ибо на сайте у вас указаны и OpenStreetMap, и MapLibre.
Вы, как мне кажется, делите шкуру не убитого медведя. На которого даже охоту не начали. Если я сказал, что это не коммерческий проект, то так и будет. Если кому-то будет полезно и захочет использовать - я не буду за ним бегать и выяснять упомянул ли он меня где, и сколько заработал на этом.
Мне, к слову, понравилась ваша идея использовать слайдер для ограничения результатов по баллам.
Можете использовать без упоминания меня!
Моё сомнение по поводу этой версии усиливается ещё и тем, что в статье вы крайне мало рассказали о процессе создания проекта.
Ну такой я человек - для меня результат, важнее процесса, и тем более его описания. Пояснения будет в коде - надо дооформить репозиторий и открыть. Кому будет интересно из кода все поймут как и что строится.
Спасибо за ответ! Я услышал вашу историю и понял, почему вы решили опубликовать ваш проект именно сейчас. Забавно, конечно, что в заключении своей статьи я задаюсь вопросом о востребованности подобных сервисов, и вот спустя некоторое непродолжительное время обнаруживаю человека, имевшего схожие наработки и решившего завершить свой проект, вдохновившись общей идеей.
Поэтому детали в вашей статье меня не сильно интересовали (давно уже этот этап сравнения пройден)...
Честно говоря, не понял, какие сравнения в моей работе вы имеете в виду, ибо до этого вы рассказывали о способах сравнения качества данных общегеографической карты, но да и ладно. Наверное, вы имели в виду, что изначально были ориентированы на анализ именно по гексагональной сетке.
Вообще то "сложение" слоев используется часто для отображения геоинформации. Многие инструменты позволяют настраивать как эти слои складываются (additive/subtractive), с какой прозрачностью. Что тут нового и уникального чтобы претендовать на авторство - не совсем понятно.
В самом деле, создание синтетических показателей — идея не новая, и в картографии она применялась ещё в печатных тематических картах. В данном случае я имел в виду, что ранее не встречал возможности настройки коэффициентов (ибо операция перемножения слоёв — это в большинстве случаев всегда 1×1, а настройка прозрачности — это всё же исключительно визуальное наложение) и применения их в сфере оценки благоприятности территорий для проживания. Поэтому был так удивлён появлению проекта с такой же идеей.
Теперь ответы на вопросы:
Можете, пожалуйста, объяснить, для чего необходимо с помощью подхода IQR заменять максимальные значения индексов перед их сложением в общий индекс?
Это делается не перед сложением, а перед нормализацией каждого отдельного индекса. Избавляется от "перекошенности" гистограммы - текущие параметры далеки от нормального распределения. Убираем максимумы и минимумы - иначе карта либо вся зелена, либо вся красная.
Выбор диапазона значений весов от -5 до 5 как-нибудь связан с необходимостью использовать межквартильный размах (IQR), или это исключительно вопрос восприятия?
Нет, не связан. Основная идея это возможно "переворачивать" индекс (используя минусовые значения коэффициента). "5" - так как данные нельзя назвать очень точными на карте, то и иметь коэффициент 100 например не имеет смысла. Первоначально была идея вообще "важно/не очень важно/пофиг" градацию использовать (может на это и перейдет).
Если не секрет, не могли бы вы рассказать немного о технической составляющей процесса перерасчёта показателей? Судя по параметрам запроса, я так понимаю, что данные изначально хранятся в векторных тайлах, которым передаются значения коэффициентов, и после эти тайлы пересчитываются и возвращаются обратно, верно? Если так, то для хранения, перерасчёта и обратной визуализации тайлов используется Martin, или какая-то из этих частей выполняется PostgreSQL? Ну, это если я в целом правильно понял логику работы.
Сами индексы хранятся в PostgreSQL - таблица с h3 полигоном и набором колонок smallint. Martin вызывает функцию в PostgreSQL, которая на основе параметров (зум, город и полигон) делает выборку, агрегирует (по h3 level 9 or level 10) в общий индекс, нормализует и упаковывает в тайл исходные индексы и общий индекс. Кэширование стоит на уровне nginx - что бы не пересчитывать одно и тоже каждый раз.
Это делается не перед сложением, а перед нормализацией каждого отдельного индекса. Избавляется от "перекошенности" гистограммы - текущие параметры далеки от нормального распределения. Убираем максимумы и минимумы - иначе карта либо вся зелена, либо вся красная.
Почему значения индексов обязательно должны подчиняться правилу нормального распределения? Если на какой-то территории действительно невероятно много или, наоборот, критически мало объектов, почему не учитывать это? Или вы исходите из предположения, что такие области — это скорее результат особенностей картографирования в OSM (когда одни территории богаты данными вследствие большой работы сообщества, а другие не обновлялись несколько лет), нежели реальное состояние местности?
Первоначально была идея вообще "важно/не очень важно/пофиг" градацию использовать (может на это и перейдет).
Мне тоже сейчас кажется, что, возможно, настройка с градацией в 10 пунктов слишком большая. Кажется, что она даёт гибкость, но на деле как будто только запутывает. Слышал мнение: «А в чём значительная разница между коэффициентами 6 и 7, 9 и 10?» Сам думал перейти к градации в 5 пунктов, но, поскольку такое мнение встретил лишь единожды, пока отложил это.
Сами индексы хранятся в PostgreSQL...
Имею мало опыта работы с перечисленными инструментами и создания взаимосвязей между ними, но общую логику я понял. Благодарю!
Почему значения индексов обязательно должны подчиняться правилу нормального распределения? Если на какой-то территории действительно невероятно много или, наоборот, критически мало объектов, почему не учитывать это? Или вы исходите из предположения, что такие области — это скорее результат особенностей картографирования в OSM (когда одни территории богаты данными вследствие большой работы сообщества, а другие не обновлялись несколько лет), нежели реальное состояние местности?
Они не должны ничему подчинять - если бы было близко к нормальному распределению, то использовался бы не IQR.
Наличие экстремумов это реальное состояние местности - но вам не обязательно знать, какая единственная (или пара) областей имеет максимальное/минимальное значение (в рамках 1000-2000 гексагонов в городе). Можно было бы разбивать на диапазоны (или персентили) и цвета ставить дискретно - тогда ничего делать не нужно было бы. Я выбрал более плавное отображение цветов - поэтому приходится немного трансформировать данные (так чтобы изменения на общую картину не влияли).
Добавлены индексы (если уже заходили на карту - нажмите Ctrl+F5):
Доступность медицины - Чем выше значение индекса тем больше поликлиник, клиник и больниц в радиусе доступности (до 2 км для клиник и 5 км для больниц). Чем ближе объект и если это больница, то тем больше его вклад в значение индекса.
Доступность спорта - Чем выше значение индекса тем больше спортивных центров и площадок в радиусе доступности (до 1 км). Чем ближе объект, тем больше его вклад в значение индекса.
Доступность парков - Чем выше значение индекса тем больше парков в радиусе доступности (до 2 км). Чем ближе парк и больше его площадь, тем больше его вклад в значение индекса.
Спасибо за сервис, интересно было посмотреть индексы тех мест, где живу/жил.
Заметил, что индекс парков рассчитывается как-то странно. Почему-то для несмотря на то, что два гексагона могут примыкать к одному парку, индексы парков у них могут быть значительно отличаться.
Бывает границы парка некорректны. Но вообще один из гексагонов ближе к парку и форма парка такова, что другой гексагон дальше. Парк рассматривается как множество гексагонов покрывающих площадь - и считаем каждый гексагон парка в индексе.
Но может и быть ошибка - кидайте в личку или сюда ссылку - проверю по данным.
Расчеты основываются на данных из OpenStreetMap (OSM). Вся информация о застройке, транспорте, школах, барах и прочих взята из тэгов различных объектов OSM.
Посмотрел на Новосибирск. Результат не очень. И да, понимаю, что проблема в исходных данных OSM, нет претензий к автору статьи. Прощёлкал отдельно все индексы (ставил 1 для одного индекса и 0 для всех остальных) и правдоподобную раскраску получил только для доступности объектов образования. Ну и по барам-ресторанам не особо ориентируюсь, не оценивал этот индекс. В целом город знаю неплохо и вижу, что остальные индексы даже приблизительно не соответствуют реальности.
Индекс твоего города