지리 공간 데이터를위한 버전 관리 시스템을 구현하고 있습니까? [닫은]

나는 여기에 정답을 즉각적으로 필요로하지는 않지만, 최근에는 지리 데이터를위한 "(분산) 버전 제어 시스템"개념을 도입하려는 노력을 보았습니다. 내가 아는 몇 가지 예는 OpenGeo ( 1 , 2 & 3 ) 의 세 백서 와 노르웨이 GIS 소프트웨어 공급 업체 및 노르웨이지도 기관 의 " Geosynkronisering (geosyncronization)"프로젝트입니다. 지리 공간 데이터의 분산 버전 도 찾았 습니까? , GeoGit (OpenGeo) 및 ArcGIS ModelBuilder 모델에 버전 제어 적용 을 언급 한 것은 무엇입니까? ArcGIS의 버전 관리에 대해

SVN 및 Git과 같은 소스 코드의 버전 제어 시스템이 작동하는 방식을 알고 (적어도 사용할 수있을 정도로) 개발자이며 지오메트리에 대한 배경 지식은 지리학 데이터에 고유 한 문제가 있음을 알려줍니다. 소스 코드 (기본적으로 텍스트)가 처리되는 방식과 완전히 유사한 방식은 아닙니다.

지리 데이터에 대한 (d) VCS를 처리 할 때 어떤 문제가 발생합니까? 어떻게 해결하고, 우리가 필요로하며, 내가 언급 한 것보다 이러한 문제를 해결하려는 다른 시도가 있습니까?

OpenGeo 백서가 내 질문 중 일부에 답할 것이라는 것을 알고 있습니다. 그러나 제가 실제로 겪고있는 것은 "10 살짜리처럼 말해줘"라는 스타일로 "교육적"답변입니다. 지리 데이터가 혼합에 가져 오는 도전과 해결책에 대한 훌륭한 설명을 사람들에게 소개 할 수 있습니다.

나는 현재 특정 문제를 해결하려고하지 않는다고 말하면서 통찰력이있는 사람이 문제에 대해 약간의 생각을하는 데 시간이 걸릴 수 있기를 희망하지만이 주제는 나에게 관심이있는 주제입니다.

현재 지리 데이터 저장소를 완전히 재 설계하고 있습니다. 나는 그들의 진화가 지금까지 20 년 이상 걸렸다 고 말해야한다. 지리 공간 데이터 관리에서 다음과 같은 주요 기능을 식별했습니다.

• 동시 편집
• 데이터의 일부를 읽거나 쓸 수있는 권한
• 데이터에 의존하는 서비스 (트랜잭션 및 ACID 패러다임)를 실행하는 동안 핫 업데이트
• 내부 및 외부 스키마 (내부 스키마를 수정하면 서비스에 영향을 미치지 않아야 함)
• 대량의 데이터 (테라 바이트의 래스터 및 기가 바이트의 벡터 데이터의 장애물)를 저장하고 액세스하는 기능
• 서로 다른 레이어 간의 데이터 일관성 (모든 소포는 지구에 속합니다)

우리는 다음과 같은 접근 방식을 평가했으며 여기에 내가 말할 수있는 것이 있습니다.

1. ESRI 엔터프라이즈 지오 데이터베이스(ArcGIS 10.1); 이전에 사용했던 것과 거의 동일하지만 (SDE) 버전 관리 기능을 사용하여 트랜잭션을 처리합니다. 그러나 그것은 실제로 Enterprise Geodatabase가 아닙니다. 제 생각에 SDE는 사람들이 오전 8시에서 오후 8 시까 지 일하는 지리 데이터 서버로 작업 그룹에서만 작동하며 유지 보수 작업을 위해 오프라인으로 가져갈 수 있습니다. 트랜잭션 커밋 (버전 조정 및 ESRI 음성으로 게시), 복제 등 ...이 데이터를 기반으로 서비스를 구축하는 경우 복제 된 프로덕션 데이터베이스 인 준비 데이터베이스 (작업이 완료된 위치)를 처리해야합니다. 이것은 프로그래밍에서의 빌드 / 테스트 및 배포와 거의 동일합니다. ESRI가 제공하는 기능이 풍부한 패키지는 상당히 훌륭하지만 유연성이 부족합니다 (스키마 변경 또는 사람들이 작업하는 동안 유지 관리 작업, 예를 들어 인덱스 생성).

2. 플랫 파일 및 버전 제어 시스템우리는 Git을 선택합니다 (GeoGit이 이미 있다는 것을 몰랐습니다). 그래, 내 친구 중 일부와 나도 소프트웨어 공학에서 왔어. 너무 간단 할 수 있습니다. 나는 그것이 문제라고 생각한다 : 그것은 자동차를 만드는 자동차 정비공과 같다. 그를 위해 유지하는 것은 간단 할 것이지만, 운전을하고 추악한 것을 확실히 보는 것은 성 가실 것이다. 나는 또한 몇 가지 주요 단점이 있다고 생각합니다 : 2 TeraByte (또는 이진) Rasterdataset의 버전 제어 방법? 그리고 어떤 형식으로? 텍스트 기반 형식 (예 : GML)을 사용하면 벡터 데이터의 버전을 쉽게 제어 할 수 있지만 10 억 개의 행 데이터 세트로 작업하기도 어렵습니다. 모든 사용자가 모든 것을 편집하거나 볼 수있는 것은 아니므로 효과적인 사용자 권한 관리를 수행 할 수 있는지 확실하지 않습니다. 그리고 동시에 4 명의 사용자가 집중적으로 편집 한 벡터 데이터 세트를 어떻게 병합합니까? 적어도이 모든 것을 효과적으로 수행하려면 실제 컴퓨터 과학자 / 프로그래머 여야합니다. GIS 사용자는 계획자, 측량사, 지질 학자 등입니다. 프로그래머가하는 것처럼 버전 계보를 생각하거나 분기 방식을 사용하는 것은 단순히 문제가됩니다. 그럼에도 불구하고 데이터 저장소를 공유 저장소로 생각하는 것은 흥미로운 아이디어입니다.

3. 간단한 컨테이너로 플랫 테이블 데이터베이스 . SDE와 동일하지만 SDE 기능이 없습니다. RDBMS가 제공하는 이점을 실제로 사용하지 않기 때문에 유지 관리가 여전히 어렵습니다. 예, 데이터베이스에 모든 것을로드하는 것은 매우 간단하지만 데이터 관리는 아닙니다.

4. Bigdata 및 NoSQL . 플랫 파일 및 플랫 테이블과 동일한 문제 제 생각에는 웹에서 사용하기위한 간단한 파일 시스템 API입니다. 예, 웹에서 잘 작동하며 문서를 쉽게 넣을 수는 있지만 테라 바이트 (래스터) 데이터에 대한 공간 데이터 분석을 수행하려면 직렬화 및 역 직렬화하지 않는 것이 좋습니다. HTTP 인터페이스를 통해.

2018 업데이트 : 여기에 많은 추진력을 창출하는 많은 새로운 것들이 있습니다. 몇 가지 예를 들면 다음과 같습니다.

• 클라우드 블록 스토리지 및 HDFS
• 파이썬 / 모양 / 다크 스택

• 아파치 스파크

  • 벡터 데이터를위한 GeoMesa / GeoWave
  • 래스터 데이터 용 GeoTrellis

• 그리고 훨씬 더

  5. 포괄적 인 클래식 데이터베이스 모델링(RDBMS 사용). 가장 큰 문제는 어디서나 데이터를 삭제하기가 어려워 향후 모든 요구에 부합되기를 희망한다는 것입니다. 그러나 데이터베이스에 강력한 데이터 모델 (OSM도 실제로 수행)을 지정하는 데 많은 시간을 투자하면 모든 장점을 활용할 수 있습니다. 분산 트랜잭션에서 데이터를 편집하고 업데이트 할 수 있으며 핵심 스키마도 수정할 수 있으며 서비스는 여전히 동일한 데이터의 외부 스키마에 의존하고 유지 보수 할 수 있으며 일관성을 검사하고 권한을 허용 및 거부 할 수 있습니다. 대량의 데이터를 저장하는 동시에 빠른 방식으로 데이터에 액세스 할 수 있으며, 내역 데이터 모델을 작성하고 투명하게 트리거 할 수 있습니다. 우리는 SQL 서버를 사용하기 때문에 여전히 기본 래스터 유형이 없지만 다른 데이터베이스 공급 업체는 이미 이것을 제공합니다.

글쎄, 관계형 데이터베이스 모델은 지난 몇 년 동안 (BLOB 컨테이너가있는 곳 이전의) 공간 데이터 유형을 가진 공간 세계에서 일어나고 여전히 가장 유연하고 전문적인 데이터 저장 형태라고 생각합니다. 그렇다고 VCS 접근 방식이나 NoSQL을 보완해서는 안된다는 것을 의미하지는 않지만 이러한 접근 방식이 전문 중앙 집중식 공간 데이터 관리의 형태보다 사용자 그룹의 데이터 분배의 형태 일 가능성이 더 높습니다. 또한 OSM은 많은 양의 데이터 가져 오기 (오스트리아의 대부분의 OSM 데이터는 하루에 크라우드 소싱이 아닌 가져 오기) 및 타일 생성과 같이 군중이 제공 할 수없는 많은 작업을 중앙 집중화했습니다. 협업 (크라우드 소싱) 부분은 실제로 매우 중요하지만 비즈니스의 절반 밖에되지 않습니다.

나는 이것을 많이 바꾸고 더 많은 사실을 제공해야한다고 생각합니다. 이와 같은 질문은 몇 시간 내에 포괄적으로 답변하기가 어렵습니다. 다음 날 내 답변의 품질을 향상 시키려고 노력할 것입니다.