Комментарии 18
Можно поподробнее, чем вариант с PostGIS будет удобнее?
Учитывая, что есть необходимость гибко работать с другими источниками данных, мое решение с ~30 строками кода не кажется таким уж сложным…
Ну там из коробки уже есть все необходимые запросы и можно писать всякие SQL выборки типа "дай все объекты попадающие в данную область и имеющие данные теги".
Плюс есть уже куча готовых инструментов, умеющих работать с PostGISовыми дампами OSM.
А вообще такие задачи часто можно решить в каком-нибудь QGIS — он умеет дофига всего в плане импорта данных и их визуализации. И кодить не надо. Хотя это зависит от бэкграунда — программисту проще написать десять строк скрипта, чем разбираться в интерфейсе QGIS.
А данные для отрисовки в кугисе можно подготовить (попиарюсь чутка) с помощью моего сервиса YourMaps (статья на Хабре про него) — там в визуальном редакторе можно настроить все необходимые фильтры по пересечениям-тегам-прочему, и получить готовый geojson.
Мне действительно было достаточно просто разобраться в библиотеке благодаря опыту работы с Pandas, которая очень похожа. Та же фильтрация на основе принадлежности к конкретному объекту делается одной строкой:
building_areas.loc[nf_buildings, 'geometry'].centroid.within(area_geo)+ роль сыграла сложность установки дополнительного ПО на рабочем оборудовании (geopandas там уже присутствовали). К тому же, подозреваю, что соединять питоновский код с другими источниками данных и прописывать различные алгоритмы (в статье это не покрыто, но требовалось в реальной работе) проще, чем при использовании дополнительного инструментария (тут могу ошибаться, тк не знаком со всем функционалом того же QGIS).
В то же время, согласен, что человеку с другим бэкграундом может быть сложнее разобраться в коде — вполне возможно, им более удобным покажется ваше решение.
Так что спасибо за комментарий и ссылки!
Незаметно для себя, вы отлично проиллюстрировали один давний вопрос, который поднимали участники OSM в России — то, что не стоит пытаться создать в базе проекта полигональные объекты, очерчивающие территорию с одним индексом. Потому что индекс — свойство адреса, адрес, в свою очередь, присваивается зданию или участку, но не административной территориальной единице. И хотя индекс может быть присвоен на основании того, что адрес находится внутри административной территории, это не всегда так происходит. Вот вы в своей проверке это доказали наглядно.
К сожалению, специфика данных требовала использовать именно индекс. Если бы не было такого требования, можно было бы использовать, например, ОКТМО.
В то же время, хотя результат и не идеален, с определенной долью погрешности индес использовать можно (см. последний график в статье).
Повторюсь, решение не идеально и обусловлено в первую очередь спецификой задачи и форматом данных, которые необходимо было визуализировать.
Я не критикую ваше решение. Просто оно, попутно, проиллюстрировало наглядно ситуацию, которая ранее в сообществе обсуждалась с теоретической точки зрения, из-за чего чистые эмпирики отказывались верно понимать ситуацию, продолжая верить, что индекс назначается некой территории, а не множеству конкретных адресов. Такая идея верна для США, например, но не для России.
Для примера, чтобы подтвердить минусы использования индексов: вот распределение зданий с кодом «127238» — одним из наиболее популярных в Москве.
У него зданий, находящихся в «основном» для этого почтового кода районе — всего 34%, виден большой разброс по городу.
Если посмотреть на уровне страны — ситуация становится еще хуже — здания с одним и тем же индексом могут быть разбросаны вообще в разных городах.
Посмотрите на вот эту выборку: overpass-turbo.eu/s/X6M
Там, правда, придется еще выкинуть офисы коммерческих перевозчиков (по признаку отсутствия свойства с шестизначным индексом).
Действительно была идея использовать почтовые отделения + диаграмму Вороного.
В итоге решили использовать данный способ, чтобы конечному пользователю было проще найти нужный район на карте (по привычному названию района, типа «Гагаринский», а не по странному многоугольнику, очерченному вокруг отделения).
Ну и к тому же, мне кажется, относительная близость к конкретному почтовому отделению не обязательно означает, что у здания будет соответствующий почтовый индекс…
В любом случае, если будет свободное время, опробую и этот метод, посмотрим, что выйдет. Например, сравнить долю расхождений между индексом, предсказанным на основе близости к отделению, и индексом, указанным у конкретного здания.
del
Первые шаги в визуализации данных с использованием Geopandas и OSM