PostGIS를 사용하여 복잡한 지오 프로세싱 워크 플로우를 처리하는 방법은 무엇입니까?

12

우리 조직은 지오 프로세싱 워크 플로우를 PostGIS로 옮기는 것을 고려하고 있습니다. 우리는 현재 ModelBuilder에서 사용되는 수많은 사용자 정의 Python 도구와 함께 ArcGIS를 사용하고 있습니다. 다양한 앱에서 사용하기 위해 대부분의 데이터를 PostGIS로 옮겼으며 이제는 데이터 처리도 수행해야하는지 묻고 있습니다.

소프트웨어와 호환되도록 데이터를 처리합니다. 고객이 소프트웨어를 구매하고 데이터를 제공하며 소프트웨어에서 사용하도록 최적화되도록 처리합니다. 이를 위해서는 다양한 품질의 입력 데이터를 처리 할 수있는 다양한 도구를 구축해야합니다. 특정 형식이나 스키마로 데이터를 수신 할 수 없으므로 입력 필드를 출력 필드에 매핑하고 단일 필드를 여러 필드로 구문 분석하고 여러 데이터 세트를 병합하는 등의 도구를 작성합니다. 또한 공간 조인, 교차, 공백 제거를 수행합니다. 필드와 다른 많은 공통 작업을 연결합니다. PostGIS는 모든 처리 요구를 완벽하게 수행 할 수있는 것으로 보입니다.

PostGIS를 사용하여 데이터 처리를 수행하는 사람들에게 조직, 사용 도구 등에 대한 조언이 있습니까?

QGIS python 처리와 함께 사용합니까?
사람들이 웹 이외의 처리를 위해 Python ORM을 사용하고 있습니까? PostGIS 용 Python ORM이 있기 때문에 GeoDjango 를 사용하는 데 기울고 있습니다. PostGIS를 사용하여 데이터를 처리하는 초기 테스트에는 Python 코드에 많은 큰 SQL 텍스트 블록이 있으며 GeoDjango ORM이 더 관리하기 쉽고 읽기 쉬운 코드를 만드는 데 도움이 될 수 있다고 생각합니다. PostGIS와 유사하게 상호 작용하고 Django만큼 웹 고유하지 않은 GeoAlchemy ORM 도 있습니다.

QGIS 또는 ArcGIS를 사용하는 사람들을 보는 것만 큼 PostGIS를 사용하여 지오 프로세싱을하는 사람들에 대해 들어 본 적이 없으므로 비슷한 대안인지 알고 싶습니다.

— 태너
소스

1

모든 프로세스가 "백엔드"입니까? 나는 Django 또는 GeoDjango 사용자는 아니지만 웹 사이트를 개발하기위한 제품을 생각합니다 (IMHO보다 가치가 있습니다). 왜 셸이나 파이썬 스크립트 만 (유닉스) 명령 줄에서 또는 주기적으로 "cron"을 통해 실행되지 않습니까? (누르면 clickey-clickey가 항상 마음에 듭니다.) 적어도 들어오는 데이터 스트림을 통해 체계적으로 구성하고 싶을 것입니다. 또한 Postgis는 QGIS 없이도 데이터를 슬라이스하고 주사위를 깎을 수 있습니다. 어떤 유형의 작업을 염두에두고 있습니까?

— forkandwait

1

예, 처리는 백엔드입니다. 그러나 결국 고객이 데이터를보고 편집 할 수있는 OpenLayers 웹 맵이 제공됩니다. 앱의 사용자 및 관리자 계정으로 Django를 사용할 수 있습니다. 그렇다면 Django가 주로 웹 사이트를 위해 제작되었지만 처리를 위해 GeoDjango를 조사 해야하는 또 다른 이유 일 수 있다고 생각했습니다. 이 대규모 처리 장고와 프리젠 테이션 장고 그냥 웹 사이트에없는 것을 제안 : slideshare.net/dibau_naum_h/large-scale-processing-with-django

— 태너

1

백엔드 작업을 위해 PostGIS, 작은 ogr2ogr, 스크립팅 언어 (Python, Ruby, Tcl 등) 및 유닉스 명령 줄을 사용합니다. 데이터베이스를 가능한 한 호환성있게 유지하는 것을 제외하고는 장고를 혼합하지 마십시오. 그런 다음 나중에 필요한 경우 프런트 엔드를 설치하십시오. 내 규칙은 다음과 같습니다. 덜 클릭 = 생산성 향상 (GIS 분석가는 클릭 클릭 클릭 쓰레기에 대해 더 편안하게 느끼지만 "직관적 인 인터페이스"를 의미합니다).

— 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의 최신 버전 이 기본 제공됩니다 . Django에서 사용자 지정 원시 SQL 쿼리를 사용하여 래스터 지원 부족과 전반적인 견고성을 보완 할 수 있습니다.

보다 강력한 지오 프로세싱 애플리케이션, 특히 객체 관계형 모델을 사용하려는 경우 GeoAlchemy2를 사용해보십시오. SQLAlchemy를 확장하는 원래 GeoAlchemy 라이브러리는 기능 데이터를 지원합니다. GeoAlchemy2 는 PostGIS 2.0의 새로운 래스터 데이터 유형에 대해 (제한적) 지원을 제공하여 이를 확장합니다 .

그리고 항상 GDAL과 OGR에 대한 파이썬 바인딩이 있습니다!

— 아서
소스

YMMV, 그러나 객체 관계형 라이브러리는 실제로 오래된 SQL에 아무것도 추가하지 않습니다. 다른 의견에서 말했듯이 구체적인 내용을 듣는 것이 가장 흥미로울 것입니다.

— forkandwait

4

사후 조사 침식 모델을위한 래스터 입력을 생성하는 웹 서비스 인 사례 연구를 설명 할 수 있습니다. 기본적으로 다수의 래스터는 서브셋이어야하고 서로 추가되어야합니다. 데이터가 저장된 PostGIS와 인터페이스하기 위해 GeoAlchemy2 (GA2)를 선택했습니다. GA2를 사용하여 재사용 가능한 소형 PostGIS 쿼리를 만들 수 있습니다. 한 번의 쿼리로 "burned land cover"제품 (랜드 커버의 재 클래스, 하위 세트)이 생성됩니다. 이 제품은 일부 모델링을 위해 자체적으로 필요하지만 토양층 인 다른 래스터에 추가되어 세 번째 출력 제품을 생성합니다. GA2를 사용하면 파이썬에서 혼합, 일치 및 직렬화 할 수 있습니다.

— Arthur

3

가능하지만 데이터베이스 엔진이나 웹 프레임 워크 내에서 많은 지오 프로세싱을 원한다고 상상하기는 어렵습니다. 기본 코드 라이브러리 인 geos, proj.4 및 gdal을 살펴 보는 것이 좋습니다. 세 가지 모두에 대한 파이썬 바인딩 또는 라이브러리가 있습니다. 살펴볼 또 다른 옵션은 QGIS 용 Sextante 지오 프로세스 플러그인입니다. 모델 / 워크 플로우 구축이 가능합니다.

다른 생각들 :

PostGIS 사용을 배제하지 마십시오. 우수한 스토리지 및 서버 기능을 제공하며 SQL을 통해 일부 지역 및 프로젝트 기능을 제공합니다. Django, QGIS 및 Python과 같은 다른 도구와도 잘 어울립니다.

앞에서 언급 한 Sextante 플러그인을 사용하는 것 외에도 QGIS는 시각화에 적합하고 postgres 작업을위한 몇 가지 도구가 있으며 Python 콘솔도 포함합니다.

ORM을 찾고 웹 프론트 엔드를 원한다면 Django가 그렇게 할 것입니다. 섹시하지 않은 인터페이스를 신경 쓰지 않으면 관리자 페이지는 GeoDjango를 사용하는 경우 지오메트리 편집조차도 거의 노력하지 않고 CRUD 인터페이스를 제공합니다.

— Scro
소스

2

지오 프로세싱을 위해 웹 프레임 워크를 사용하지 않을 것에 동의하지만 지리 프로세싱을 수행하기 위해 PostGIS (또는 다른 데이터베이스 엔진)를 사용하지 않을 것에 강력하게 동의하지 않습니다. 토론에서 앞으로 나아가려면 구체적인 내용이 필요하지만 PostGIS 및 SQL을 사용하여 방대한 양의 형상 슬라이싱 / 다이 싱 및 Point-in-Poly 분석을 수행합니다.

— forkandwait

2

@forkandwait 아, PostGIS에 동의합니다. 그러나 각 프로젝트마다 다르게 연결될 수있는 여러 개의 작은 스크립트를 사용한다는 인상을 받았습니다. 저의 목표는 그들이 가장 적합한 환경을 선택할 수 있도록 기본 라이브러리를 조사하도록하는 것이 었습니다.

— Scro

3

공간 작업 (또는 오픈 소스 GeoKettle )을 위한 ETL , 특히 FME 를 살펴보십시오 .

시각적 워크 플로를 만들 때 FME를 사용하는 것이 정말 좋습니다. 공간 작업, 조인, 병합 등 모든 것에 대한 논리를 분리 할 수 있으며 데이터베이스 이외의 형식 및 다른 데이터베이스로 작업 할 수 있습니다. 많은 일을 쉽고 쉽고 빠르게 수행하십시오. 모델 빌더에 대한 경험이 있다면 온라인으로 많은 문서를 얻을 수있을 것입니다.

FME의 유일한 단점은 비용이 든다는 것입니다. 하지만 그만한 가치가 있다고 생각합니다.

FME를 사용하는 것에 대한 대안은 아마도 GDAL과 OGR과 함께 파이썬을 묶을 수 있습니다. 또는 PostgreSQL에서 모든 것을 수행하십시오. ETL은 공간 데이터 랭 글링에서 강력한 역할을 수행하며 데이터베이스에서만 할 수없는 일을 많이합니다.

나는 그것을 사용하지는 않았지만 GeoServer는 WPS 구현을 제공하지만 이것을 사용하지는 않았지만 다른 사람들이 이것이 당신에게 어떻게 도움이 될 수 있는지에 대해 언급 할 수 있습니까?

GeoDjango 사용에 대해서는 언급 할 수 없지만 데이터를보기위한 프론트 엔드와 같은 CMS라고 생각했습니다.

— 알렉스 레이스
소스