대량의 지리 공간 데이터를 관리하십니까? [닫은]

지리 공간 데이터는 어떻게 관리합니까? 수백 개의 데이터 세트에 테라 바이트 단위의 데이터가 분산되어 있으며 각 데이터 세트의 도메인 이름 기반 아카이브 디렉토리로 다시 연결되는 프로젝트 내의 기호 링크를 사용하는 임시 솔루션이 있습니다. 이것은 대부분 작동하지만 자체 문제가 있습니다.

또한 누군가가 수정 제어 시스템에서 지리 공간 데이터를 관리하는지 듣고 싶습니다. 현재 코드 및 작은 데이터 세트에는 하나를 사용하지만 전체 데이터 세트에는 사용하지 않습니다.

나는 주식 / 명백한 대답은 esri의 GeoPortal 또는 오픈 소스 GeoNetwork 응용 프로그램과 같은 메타 데이터 서버와 함께 공간 데이터베이스 (PostGIS, Oracle, SDE, MSSQL Spatial 등)를 사용하는 것이라고 생각합니다. 최고의 솔루션. 그러나 항상 프로젝트 기반 스냅 샷 / 분기 / 태그가 필요할 수 있습니다. 고급 데이터베이스 중 일부는이를 관리하는 방법이 있지만 일반적으로 사용자 / 관리가 쉬운 것은 아닙니다.

데이터베이스 외부에 저장하는 것 (큰 이미지, 프로젝트 기반 파일)의 핵심은 일관된 명명 규칙을 사용하고 메타 데이터 레지스트리 (스프레드 시트와 같은 첨단 기술조차도)를 추적하고 추적 할 수있는 것입니다. 제대로 관리되도록하십시오. 예를 들어, 프로젝트 기반 파일의 경우 이는 레코드 관리 정책이 지시 할 때 파일을 삭제하거나 프로젝트 완료시 중앙 저장소로 롤백하는 것을 의미 할 수 있습니다.

그래도 흥미로운 해결책을 보았습니다 ...

BC 주 환경부가 아크 / 정보 적용 범위를 벗어 났을 때, 그들은 정말 멋진 rsync 기반 양방향 동기화 프로세스를 갖추고있었습니다. 중앙 제어하에 있던 범위는 매일 밤 지역으로 밀려 났고 지역 데이터는 다시 밀려났습니다.이 블록 수준의 차등 전송은 56k 이상의 링크에서도 실제로 잘 작동했습니다. Oracle 기반 속성 데이터베이스를 복제하는 데 비슷한 프로세스가 있었지만 전화 접속보다 너무 잘 수행되지 않았다고 생각합니다. :)

나의 현재 직장은 비슷한 하이브리드 솔루션을 사용합니다. 각 데이터 세트에는 권한있는 사본 (일부는 Oracle, 다른 MapInfo, 다른 개인 지오 데이터베이스)이 있으며 FME를 사용하여 야간에 교차 ETL됩니다. 유지 관리와 관련하여 여기에는 상당히 큰 오버 헤드가 있습니다. 새로운 데이터 세트를 만들고 조직의 가시성이 예상보다 훨씬 높아지도록하는 노력. 우리는 이러한 오버 헤드를 피하기 위해 통합 할 수있는 방법을 찾기 위해 검토 중입니다.

여기서 메타 데이터는 가장 중요한 문제입니다. 메타 데이터가 누구에게 언제, 왜, 어디 에서 수용 가능한 메타 데이터 레코드 인지 대답 합니다.

GIS 사용자 (30 명 정도) 만있는 대기업에서 업무 경험을 쌓으면서 데이터, 특히 버전 및 권한을 제어하는 ​​데 중요한 문제가있었습니다. 이 중 하나는 광범위한 데이터 문서화 (메타 데이터)로 해결할 수 있으며 다른 문제는 PostGIS가 빛나는 중앙 저장소를 통해 해결 될 가능성이 높습니다.

GeoNetwork는 메타 데이터 문제를 다루기위한 좋은 시작입니다. 중앙 저장소를 해결하는 것은 데이터베이스를 설계 / 유지 관리하는 데 전문 인력이 필요할 수 있으므로 더 복잡합니다.

복잡한 문제는 누가 QA / QC를 담당하고 누가 이러한 데이터 세트와 메타 데이터를 담당 할 것인가입니다. 컴퓨터 기반 프로세스는 훌륭하게 작동하지만,이 회사에서 만든 우수한 데이터 관리자 / 데이터 관리자만큼 엄격 할 수는 없습니다. 이제는 메타 데이터를 검토 / 커밋하고 DBMS에 집중되지 않은 지리 공간 데이터를 구성 할 수있는 사람이 있습니다.

우리는 다음과 같이 계층 적으로 구성된 파일 시스템을 사용했습니다.-지리적 범위 (국가 또는 대륙)-데이터 제공자, 라이센스 제공자-도메인 / 데이터 세트-날짜 / 버전

그런 다음 회사 내에서 생성 한 파생 데이터 세트에서 소스 데이터 (제공자로부터받은 CD / DVD와 동일한 형식으로)를 분리하는 정책이 있습니다.

파일 시스템을 사용하면 고객의 데이터를 실제로 쉽게 수집 할 수 있으며 물리적 스토리지 측면에서 융통성이 있습니다. 아카이브를 더 크고 느린 디스크에 보관하고 특수 파일 서버 (투명하게 계층 구조에 연결됨)를 갖습니다. 더 자주 사용되는 데이터 세트.

프로젝트 내에서 관리를 용이하게하기 위해 기호 링크를 사용합니다. 벡터를 데이터베이스 (Oracle)에 보관하고 고객 당 하나 이상의 데이터베이스 인스턴스 (및 프로젝트의 여러 사용자 / 스키마)를 갖는 규칙을 만듭니다. 그러나 많은 래스터는 데이터베이스 외부에 너무 많은 공간을 차지하는 경향이 있으므로 데이터베이스에 많은 래스터를 유지하지 않았습니다. 또한 데이터베이스 인스턴스를 최대한 가볍게 유지하려고합니다.

그리고 네, 우리는 모든 것을 '경찰'하는 담당자가있어서 너무 지저분하지 않습니다.

현재이 설정에서 가장 큰 문제는 전체 사용자에 대한 더 나은 개요를 제공하는 데 도움이되는 멋진 사용자 인터페이스가 없다는 것입니다. 우리는 여전히 여기에서 옵션을 고려하고 있습니다.

우리는 코드에 버전 제어를 사용하고 문서에 사용했지만 실제로는 대부분 이진 파일 인 경우 큰 데이터 세트에 대해 버전 제어가 실제로 이루어지지 않는다는 것이 밝혀졌습니다. GML 또는 이와 유사한 텍스트와 같은 것을 처리하는 경우를 제외하고 (문제는 서버 측 디스크 사용에 대한 오버 헤드와 거대한 리포지토리를 체크 아웃 할 때 클라이언트가 충돌하는 것을 포함합니다).

@JasonBirch가 말했듯이 버전 관리는 큰 문제입니다.

또한 적절한 워크 플로가 매우 중요하다는 것을 알았습니다. 예를 들어 필드 데이터를 수집 할 때 마스터 데이터 세트에 병합되기 전에 필드 데이터를 QA 할 수있는 준비 데이터베이스를 사용하는 경향이 있습니다. QA해야하는 데이터 양에 따라 항상 약간의 오버 헤드가 발생합니다.

또한 보지 못했다면 Lars Brodersen 의 지리 통신 및 정보 디자인 전자 책을 살펴 보는 것이 좋습니다 . 적어도 그가 데이터 모델링에 대해 말해야 할 내용 중 일부에 대해서는.

Postgres는 다른 사람들이 말했듯이 휴대 성이 뛰어나고 움직이기 쉽게 유지하려면 항상 SQLite + Spatialite 확장을 사용할 수 있습니다.

관리 도구 측면에서 Postgres만큼 사용하기 쉽지는 않지만 QGis는 문제없이 공간적 지원 GIS 데이터베이스와 직접 통신 할 수 있습니다.

실제로 백업을 위해 SQLite + Spatialite를 사용하고 PGSql 인스턴스를 모니터링하는 백그라운드에서 실행되는 Windows 서비스 (사용자 정의 작성)가 있으며 GIS 데이터를 외부 USB 드라이브에있는 다양한 SQLite DB에 미러링합니다.

PG에 대한 또 하나의 팁, 스키마 사용

내가 아는 많은 사람들은 "공개"로 모든 것을 버리고 처리해야하지만 데이터베이스를 올바르게 구성하면 차이의 세계가됩니다.

예를 들어, "Ordnance_Survey"데이터베이스에는 VectormapDistrict VectormapLocal Topo50 LookupGrids CodePointWithPolygons CodePointOpen에 대한 스키마가 있습니다.

모든 관련 데이터를 보관합니다.

한편 지오메트리 열 등의 메타 데이터 테이블은 모두 공개로만 제공되며 Postgis 확장은 공개 스키마에서만 사용할 수 있지만 사용중인 다른 모든 스키마에서 액세스 할 수 있습니다.

이전 게시물에서 언급했듯이 공간 DB와 메타 데이터 서버가 일반적인 설정입니다. 기억해야 할 한 가지 핵심 사항은 '하나의 크기가 모든 것에 맞지 않는다'는 것입니다. Oracle, 파일 서버, SQL 서버 등에 가장 적합한 데이터로 끝납니다. 모든 데이터 요구 사항을 하나의 솔루션으로 해결하려고 시도했지만 일반적으로 실패합니다.

데이터에 맞는 다양한 솔루션을 사용하고 계획을 세우십시오. 이것은 지리적 포털 (메타 데이터 서버)이 실제로 들어오는 곳입니다.

메타 데이터가 지리 공간 데이터를 관리하는 데 큰 역할을해야한다는 위의 'George'에 동의해야합니다. 실제로 모든 디지털 데이터에서 메타 데이터는 핵심입니다. 적절한 메타 데이터없이 자신의 디지털 사진 파일을 관리하려는 사진 작가를 생각해보십시오. 종교적으로 사물을 태그하고 데이터를 활용할 수있는 훌륭한 소프트웨어를 갖추면 인생이 훨씬 쉬워집니다. 이제 '지리 공간 데이터 관리'에 대한 원래 질문은 상당히 광범위합니다. 이것은 저장할 데이터 형식, 명명 규칙, 데이터 세트 및 기능의 계층, 역할 및 권한 편집 등이 될 수 있습니다.

지리 공간 데이터의 스토리지 패턴은 쿼리 방법 / 데이터로 수행하려는 작업에 따라 다릅니다. 다음은 고려할 수있는 몇 가지 도구입니다.

Postgres + PostGIS : 지리 공간 인덱스 및 상상할 수있는 모든 종류의 쿼리를 지원합니다. 테라 바이트 단위의 데이터를 관리하려면 샤딩, 쿼리 최적화 등을 적용해야합니다. 쓰기로드가 많은 경우에는 권장하지 않습니다.

MongoDB : 대량의 데이터를 지원합니다. 간단한 저장, 검색 및 제한된 지형 공간 쿼리에 적합합니다.

파일 저장 : 실제로 보관 시스템에 불과하고 쿼리에 데이터의 일부만 사용하는 경우 데이터를 파일로 저장하는 것이 경제적 일 수 있습니다. 버전 관리 요구 사항이 이에 만족할 수 있습니다.

Redis : 위의 옵션 중 하나를 Redis Geo 지원과 결합하여 자주 액세스해야하는 소량의 '핫'데이터를 redis에 저장할 수 있습니다. 이것을 캐시로 생각하십시오.