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