Як використовувати PostGIS для обробки складних робочих процесів геопроцедури?

12

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

Ми обробляємо дані, щоб вони були сумісні з нашим програмним забезпеченням. Клієнт купує наше програмне забезпечення, надає нам свої дані, і ми обробляємо його для оптимізації для використання в нашому програмному забезпеченні. Це вимагає від нас створення різноманітних інструментів для обробки різних вхідних даних. Ми не можемо розраховувати на отримання даних у певному форматі чи схемі, тому ми створюємо інструменти для відображення полів введення для полів виводу, розбору окремих полів у декілька полів, об'єднання декількох наборів даних тощо. Також ми виконуємо просторові з'єднання, перехрестя, обрізання пробілів і об'єднати поля, і багато інших загальних операцій. Здається, PostGIS є абсолютно здатним виконувати всі наші потреби в обробці.

Для тих із вас, хто використовує PostGIS для обробки даних, чи є у вас поради щодо організації, інструментів для використання тощо?

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

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

— Загар
джерело

1

Чи весь ваш процес "заднім числом"? Я не користувач Django чи GeoDjango, але думаю про ці продукти лише для розробки веб-сайтів (і більше проблем, ніж вони варті, IMHO). Чому не просто купа скриптів оболонки чи python виконуються у командному рядку (звичайно, Unix) або періодично через "cron"? (Менше на мою думку завжди краще клік-клік.) Ви, мабуть, хочете систематизувати це, принаймні, за допомогою вхідного потоку даних. Також Postgis, ймовірно, може нарізати та порізати ваші дані без QGIS - які конкретні типи операцій ви маєте на увазі?

— forkandwait

1

Так, наша обробка - це бекенд. Однак ми з часом створимо веб-карту OpenLayers, щоб клієнти могли переглядати та редагувати свої дані. Ми можемо використовувати Django для облікових записів користувачів та адміністраторів програми. Якщо так, я подумав, що це може бути ще однією причиною шукати GeoDjango для обробки, хоча Django був створений в основному для веб-сайтів. Ця велика обробка масштабу за допомогою програми Django дозволяє припустити, що Django не лише для веб-сайтів: slideshare.net/dibau_naum_h/large-scale-processing-with-django

— Таннер

1

Для роботи в резервному режимі я б використовував PostGIS, трохи ogr2ogr, мову сценаріїв (Python, Ruby, Tcl, що завгодно) та командний рядок unix. Я б не намагався змішати Django в це, за винятком того, щоб зберегти вашу базу даних максимально сумісною з нею. Потім пізніше покладіть на нього передній кінець, якщо вам це потрібно. Моє правило: менш клік = більш продуктивний (хоча аналітики ГІС відчувають себе більш комфортно з лайком клік-клік ... я маю на увазі "інтуїтивні інтерфейси").

— forkandwait

Що стосується слайд-шоу - це виглядає божевільно складним і, можливо, доречним, якщо ви оподаткуєте свою обробну потужність, намагаючись не відставати, але в іншому випадку кошмарним керуйте.

— forkandwait

1

Кілька загальних питань etl, які вам можуть бути корисними: " Просторові порівняння ETL " та " Чи є безпечні альтернативи fme? "

— 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. Як я вже говорив в іншому коментарі, було б найцікавіше почути конкретику.

— forkandwait

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 хороший для візуалізації, має деякі інструменти для роботи з постгресами, а також включає консоль Python.

Якщо ви шукаєте ORM і хочете веб-передовій, Django зробить це. Якщо ви не заперечуєте проти менш сексуального інтерфейсу, сторінки адміністратора нададуть вам CRUD-інтерфейс з відносно невеликими зусиллями - навіть редагування геометрії, якщо ви використовуєте GeoDjango.

— Скро
джерело

2

Хоча я погоджуюся з тим, що не можна використовувати веб-фреймворк для геопроцесори, я категорично не погоджуюся з тим, що не можна використовувати PostGIS (або інший механізм баз даних) для геопроцесорної обробки. Нам потрібна специфіка, щоб рухатись вперед в дискусії, але я роблю величезну кількість геометрії нарізки / дикінгу та точного в полі аналізу за допомогою PostGIS та SQL.

— forkandwait

2

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

— Scro

3

Погляньте на ETL , зокрема, FME для просторових операцій (або з відкритим кодом GeoKettle ).

Мені дуже подобається використовувати FME, оскільки він створює візуальний робочий процес, і ви можете відокремити логіку просторових операцій, об'єднати, об'єднати ... все, і ви можете працювати з форматами, які не мають бази даних, і різними базами даних ... Ви можете робити багато, і просто, і швидко. Якщо у вас є досвід роботи з конструктором моделей, ви підберете це швидко, а також є багато документації в Інтернеті.

Єдиним недоліком FME є те, що він коштує грошей. Але я думаю, що воно того варте.

Альтернатива використанню FME - це, мабуть, GDAL та OGR, а також, можливо, Python, щоб поєднати його. Або, як ви кажете, роблячи це все в PostgreSQL. Я думаю, що ETL відіграє важливу роль у керуванні просторовими даними, і це дуже багато, що ви не можете зробити лише у своїй базі даних.

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

Я не можу коментувати використання GeoDjango, але я подумав, що це більше CMS, як фронтальний перегляд даних.

— Алекс Лейт
джерело