Как использовать PostGIS для обработки сложных рабочих процессов геообработки?

12

Наша организация рассматривает возможность переноса нашего процесса геообработки в PostGIS. В настоящее время мы используем ArcGIS с множеством пользовательских инструментов Python, используемых в ModelBuilder. Мы перемещаем большую часть наших данных в PostGIS для использования различными приложениями, и теперь мы спрашиваем, имеет ли смысл также выполнять обработку данных там же.

Мы обрабатываем данные для совместимости с нашим программным обеспечением. Клиент покупает наше программное обеспечение, передает нам свои данные, и мы обрабатываем их, чтобы оптимизировать их для использования в нашем программном обеспечении. Это требует от нас создания различных инструментов для обработки различных качеств входных данных. Мы не можем ожидать получения данных в определенном формате или схеме, поэтому мы создаем инструменты для сопоставления входных полей с выходными полями, разбора отдельных полей на несколько полей, объединения нескольких наборов данных и т. Д. Мы также выполняем пространственные объединения, пересечения, обрезку пробелов. и объединять поля и многие другие общие операции. PostGIS, по-видимому, вполне способен выполнить все наши потребности в обработке.

Для тех из вас, кто использует PostGIS для обработки данных, есть ли у вас какие-либо рекомендации по организации, инструментам и т. Д.?

Вы используете его в сочетании с обработкой Python QGIS?
люди используют Python ORM для не веб-обработки? Я склонялся к использованию GeoDjango, так как он имеет Python ORM для PostGIS. Наш первоначальный тест использования PostGIS для обработки данных содержит много больших текстовых блоков SQL в коде Python, и мы думаем, что GeoDjango ORM может помочь в создании более управляемого и читаемого кода. Также есть ORM GeoAlchemy, который аналогичным образом взаимодействует с PostGIS и, по-видимому, не настолько специфичен для сети, как Django.

Я не слышал о людях, использующих PostGIS для геообработки, так много, как я вижу людей, использующих QGIS или ArcGIS, поэтому я хочу знать, является ли это сопоставимой альтернативой.

— дубильщик
источник

1

Является ли весь ваш процесс "бэкэндом"? Я не пользователь Django или GeoDjango, но я думаю об этих продуктах только для разработки веб-сайтов (и больше проблем, чем они того стоят, ИМХО). Почему бы просто не запустить несколько сценариев оболочки или Python из командной строки (конечно, для Unix) или периодически через «cron»? (Меньше щелчков-кликов всегда лучше, на мой взгляд.) Возможно, вы захотите систематизировать их, по крайней мере, по потоку входящих данных. Кроме того, Postgis, вероятно, может нарезать и нарезать данные без QGIS - какие конкретные типы операций вы имеете в виду?

— форкэндвайт

1

Да, наша обработка является бэкэндом. Однако в конечном итоге у нас будет веб-карта OpenLayers, чтобы клиенты могли просматривать и редактировать свои данные. Мы могли бы использовать Django для учетных записей пользователя и администратора приложения. Если это так, я подумал, что это может быть еще одной причиной, чтобы посмотреть GeoDjango для обработки, хотя Django был создан в основном для веб-сайтов. Эта крупномасштабная обработка с использованием презентации Django предполагает, что Django предназначен не только для веб-сайтов: slideshare.net/dibau_naum_h/large-scale-processing-with-django

— Tanner

1

Для серверной работы я бы использовал PostGIS, небольшой ogr2ogr, язык сценариев (Python, Ruby, Tcl и т. Д.) И командную строку unix. Я бы не пытался смешивать Django с этим, за исключением того, чтобы ваша база данных была максимально совместима с ней. Затем, если вам это нужно, наденьте на него передний конец. Мое правило: меньше кликов = более продуктивно (хотя ГИС-аналитики чувствуют себя более комфортно с хламом клик-клик ... я имею в виду «интуитивно понятные интерфейсы»).

— Воскресенье

Что касается слайдов - это выглядит безумно сложно, и, возможно, уместно, если вы облагаете налогом свою вычислительную мощность, пытаясь не отставать, но в остальном кошмарно управлять.

— форкэндвэйт

1

Несколько общих вопросов о etl , которые могут оказаться для вас полезными: « Пространственные сравнения ETL » и « Есть ли безопасные альтернативы? »

— RyanKDalton

8

Мне действительно нравится использовать PostGIS для целей геообработки.

Мои два главных человека:

1) Зачастую сложные задачи в базе данных выполняются намного быстрее, потому что вы получаете помощь планировщика запросов для выполнения действий в правильном порядке.

2) Просто сохраните строки sql, которые вы использовали в текстовом файле, и у вас будет очень хорошая документация о том, что вы сделали.

Мой рабочий процесс, если задачи включают в себя много «шагов», используются для того, чтобы быть чем-то вроде:
1- Построить части запроса или все в зависимости от характера задачи.
2- Тестировать запрос на небольшой части набора данных, чтобы Посмотрите, как он работает.
3. Сделайте некоторую подстройку, если необходимо.
4. Запустите запрос ко всему набору данных.
5. Сохраните строки в текстовом файле с некоторыми примечаниями.
Все это часто происходит так же быстро, как запуск ArcGIS и ожидание лицензии на сервере лицензий.

— Никлас Авен
источник

5

Мы используем PostGIS и некоторую среду программирования Python для разработанных нами веб-сервисов геообработки ряда продуктов; нет претензий!

GeoDjango - отличный выбор, если вы работаете в основном (или исключительно) с функциями веб-приложения. Он не поддерживает тип растровых данных PostGIS Raster или PostGIS 2.0. Сейчас он изначально поставляется с последней версией Django. Вы можете восполнить недостаток растровой поддержки и общей надежности, используя пользовательские необработанные SQL-запросы в Django.

Для более надежных приложений геообработки, особенно если вы хотите использовать объектно-реляционную модель, попробуйте GeoAlchemy2. Оригинальная библиотека GeoAlchemy, которая расширяет SQLAlchemy, обеспечивает поддержку данных объектов; GeoAlchemy2 расширяет его , предоставляя (ограниченную) поддержку нового типа растровых данных в PostGIS 2.0.

Кроме того, всегда есть привязки Python для GDAL и OGR!

— Артур
источник

YMMV, но я считаю, что объектно-реляционные библиотеки ничего не добавляют к простому старому SQL. Как я сказал в другом комментарии, было бы очень интересно услышать конкретику.

— форкэндвайт

4

Я могу описать пример: веб-сервис для генерации растровых входов для модели эрозии после пожара. В основном, множество растров должно быть подмножеством и добавлено друг к другу. Я выбрал GeoAlchemy2 (GA2) для взаимодействия с PostGIS, где хранятся данные. Используя GA2, я могу создавать компактные, многократно используемые запросы PostGIS. Один запрос создает продукт «сожженный растительный покров» (переклассификация растительного покрова, подмножество). Этот продукт нужен сам по себе для некоторого моделирования, но также добавляется в другой растр, слой почвы, для создания третьего выходного продукта. GA2 позволяет мне смешивать, сопоставлять и сериализовать в Python.

— Артур

3

Хотя это и возможно, трудно представить, что вы захотите выполнить много геообработки внутри механизма базы данных или веб-фреймворка. Я рекомендую вам взглянуть на базовые библиотеки кода - geos, proj.4 и gdal. Есть привязки Python или библиотеки для всех трех. Другой вариант - подключаемый модуль геообработки Sextante для QGIS, поскольку он позволяет строить модель / рабочий процесс.

Некоторые другие мысли:

Не исключаю использование PostGIS. Он обеспечивает хорошие возможности хранения и сервера, а также предоставляет некоторые функции geos и proj.4 через SQL. Он также хорошо работает с другими упомянутыми инструментами: Django, QGIS и Python.

Помимо возможного использования вышеупомянутого плагина Sextante, QGIS хорош для визуализации, имеет несколько инструментов для работы с postgres, а также включает консоль Python.

Если вы ищете ORM и хотите веб-интерфейс, Django сделает это. Если вы не возражаете против менее сексуального интерфейса, страницы администратора предоставят вам интерфейс CRUD с относительно небольшими усилиями - даже редактирование геометрии, если вы используете GeoDjango.

— SCRo
источник

2

Хотя я согласен с тем, что нельзя использовать веб-среду для геообработки, я категорически не согласен с тем, что не следует использовать PostGIS (или другой механизм базы данных) для геообработки. Нам нужны подробности, чтобы продвинуться вперед в обсуждении, но я делаю огромное количество нарезки / нарезания геометрии и анализа «точка-в-поли» с использованием PostGIS и SQL.

— форкэндвайт

2

@forkandwait О, я согласен с тобой на PostGIS. Однако у меня сложилось впечатление, что они используют несколько небольших скриптов, которые они могут по-разному объединять для каждого проекта. Моя цель состояла в том, чтобы заставить их исследовать базовые библиотеки, чтобы они могли выбирать, какая среда работала лучше всего.

— Scro

3

Взгляните на ETL , в частности, FME для пространственных операций (или GeoKettle с открытым исходным кодом ).

Мне действительно нравится использовать FME, так как он создает визуальный рабочий процесс, и вы можете отделить логику для пространственных операций, объединений, слияний ... всего, и вы можете работать с не-форматами баз данных и различными базами данных ... Вы можете Делать много и легко, и быстро. Если у вас есть опыт работы с конструктором моделей, вы быстро его освоите, к тому же в Интернете много документации.

Единственный недостаток предприятия состоит в том, что он стоит денег. Но я думаю, это того стоит.

Альтернативой использованию FME, вероятно, являются GDAL и OGR, а также, возможно, Python, чтобы связать их вместе. Или, как вы говорите, делаете все это в PostgreSQL. Я думаю, что ETL играет важную роль в распределении пространственных данных, и он делает многое, чего нельзя сделать только в своей базе данных.

Я не использовал его, но GeoServer предоставляет реализацию WPS , я не использовал это, но другие могут прокомментировать, как это может быть полезно для вас?

Я не могу комментировать использование GeoDjango, но я подумал, что это скорее CMS, как интерфейс для просмотра данных.

— Алекс Лейт
источник