Спасибо, на досуге изучу.
Мне действительно было достаточно просто разобраться в библиотеке благодаря опыту работы с Pandas, которая очень похожа. Та же фильтрация на основе принадлежности к конкретному объекту делается одной строкой:
+ роль сыграла сложность установки дополнительного ПО на рабочем оборудовании (geopandas там уже присутствовали). К тому же, подозреваю, что соединять питоновский код с другими источниками данных и прописывать различные алгоритмы (в статье это не покрыто, но требовалось в реальной работе) проще, чем при использовании дополнительного инструментария (тут могу ошибаться, тк не знаком со всем функционалом того же QGIS).
В то же время, согласен, что человеку с другим бэкграундом может быть сложнее разобраться в коде — вполне возможно, им более удобным покажется ваше решение.
Так что спасибо за комментарий и ссылки!
Действительно была идея использовать почтовые отделения + диаграмму Вороного.
В итоге решили использовать данный способ, чтобы конечному пользователю было проще найти нужный район на карте (по привычному названию района, типа «Гагаринский», а не по странному многоугольнику, очерченному вокруг отделения).
Ну и к тому же, мне кажется, относительная близость к конкретному почтовому отделению не обязательно означает, что у здания будет соответствующий почтовый индекс…
В любом случае, если будет свободное время, опробую и этот метод, посмотрим, что выйдет. Например, сравнить долю расхождений между индексом, предсказанным на основе близости к отделению, и индексом, указанным у конкретного здания.
Понял, тогда мы говорим об одном — пример с США я даже сам упомянул.
Для примера, чтобы подтвердить минусы использования индексов: вот распределение зданий с кодом «127238» — одним из наиболее популярных в Москве.
У него зданий, находящихся в «основном» для этого почтового кода районе — всего 34%, виден большой разброс по городу.
Если посмотреть на уровне страны — ситуация становится еще хуже — здания с одним и тем же индексом могут быть разбросаны вообще в разных городах.
Абсолютно согласен!
К сожалению, специфика данных требовала использовать именно индекс. Если бы не было такого требования, можно было бы использовать, например, ОКТМО.
В то же время, хотя результат и не идеален, с определенной долью погрешности индес использовать можно (см. последний график в статье).
Повторюсь, решение не идеально и обусловлено в первую очередь спецификой задачи и форматом данных, которые необходимо было визуализировать.
Спасибо за комментарий!
Можно поподробнее, чем вариант с PostGIS будет удобнее?
Учитывая, что есть необходимость гибко работать с другими источниками данных, мое решение с ~30 строками кода не кажется таким уж сложным…
Мне действительно было достаточно просто разобраться в библиотеке благодаря опыту работы с Pandas, которая очень похожа. Та же фильтрация на основе принадлежности к конкретному объекту делается одной строкой:
+ роль сыграла сложность установки дополнительного ПО на рабочем оборудовании (geopandas там уже присутствовали). К тому же, подозреваю, что соединять питоновский код с другими источниками данных и прописывать различные алгоритмы (в статье это не покрыто, но требовалось в реальной работе) проще, чем при использовании дополнительного инструментария (тут могу ошибаться, тк не знаком со всем функционалом того же QGIS).
В то же время, согласен, что человеку с другим бэкграундом может быть сложнее разобраться в коде — вполне возможно, им более удобным покажется ваше решение.
Так что спасибо за комментарий и ссылки!
Действительно была идея использовать почтовые отделения + диаграмму Вороного.
В итоге решили использовать данный способ, чтобы конечному пользователю было проще найти нужный район на карте (по привычному названию района, типа «Гагаринский», а не по странному многоугольнику, очерченному вокруг отделения).
Ну и к тому же, мне кажется, относительная близость к конкретному почтовому отделению не обязательно означает, что у здания будет соответствующий почтовый индекс…
В любом случае, если будет свободное время, опробую и этот метод, посмотрим, что выйдет. Например, сравнить долю расхождений между индексом, предсказанным на основе близости к отделению, и индексом, указанным у конкретного здания.
Для примера, чтобы подтвердить минусы использования индексов: вот распределение зданий с кодом «127238» — одним из наиболее популярных в Москве.
У него зданий, находящихся в «основном» для этого почтового кода районе — всего 34%, виден большой разброс по городу.
Если посмотреть на уровне страны — ситуация становится еще хуже — здания с одним и тем же индексом могут быть разбросаны вообще в разных городах.
К сожалению, специфика данных требовала использовать именно индекс. Если бы не было такого требования, можно было бы использовать, например, ОКТМО.
В то же время, хотя результат и не идеален, с определенной долью погрешности индес использовать можно (см. последний график в статье).
Повторюсь, решение не идеально и обусловлено в первую очередь спецификой задачи и форматом данных, которые необходимо было визуализировать.
Можно поподробнее, чем вариант с PostGIS будет удобнее?
Учитывая, что есть необходимость гибко работать с другими источниками данных, мое решение с ~30 строками кода не кажется таким уж сложным…