OpenStreetMap에서 버전 관리를 처리하는 방법은 무엇입니까?

보다 일반적인 의미로 지리 공간 데이터 관리라는 주제가 여기에 나왔습니다 . 버전 관리 주제도 언급되었지만 실제로 다루지는 않았습니다.

기존 지리 공간 데이터 수집 및 유지 관리는 데이터베이스가 조직 내에서만 업데이트되므로 내부적으로 버전 관리 만 처리하면됩니다. OpenStreetMap과 같은 크라우드 소싱 된 지오 데이터베이스에서는 그렇지 않습니다. 거기에서 누구나 와서 객체를 추가, 수정 또는 삭제할 수 있습니다. OpenStreetMap에서 이것은 기본적인 방법으로 처리됩니다. 각 객체는 정수 버전 번호를 가지며 가장 높은 버전의 객체 만 라이브 데이터베이스에 노출됩니다. 데이터베이스는 낙관적 잠금을 사용하므로 사용자가 컨트 리뷰 션을 수동으로 업로드 할 때 발생하는 모든 충돌을 해결해야합니다.

편집자 ( JOSM , Potlatch )를 통한 인적 기여 가 유일한 기여 방식 인 한 , 이 모든 것이 합리적으로 효과 가 있습니다. 공개 공공 부문 데이터의 수입이 증가하고 있습니다. 이로 인해 더 복잡한 버전 관리 문제가 발생합니다. 다음 시나리오를 고려하십시오.

1. 공개 공공 부문 데이터 세트에서 건물 객체를 가져 오는 중
2. 건물은 인간 기고자 (속성, 지오메트리 또는 둘 다)에 의해 일부 수정을받습니다.
3. 공공 부문 데이터의 새 버전이 제공되고 가져옵니다.

현재 3 단계에서 커뮤니티 수정을받은 각 건물이 새 가져 오기와 수동으로 병합되지 않는 한 인적 기여는 상실됩니다.

OpenStreetMap은이 상황을 어떻게 처리 할 수 ​​있습니까? 소프트웨어 개발에서 분산 버전 제어를 검토해야합니까? 분산 공간 데이터 유지 관리를 처리하기 위해 DVC 방법을 어떻게 조정할 수 있습니까?

GIS 데이터에 대한 비파괴 편집을 구현하는 사람을 꿈꿨습니다. 계산 집약적이지만 RDBMS에서 구현하기 어려워서는 안됩니다.

데이터의 스냅 샷으로 시작하십시오. 모든 변경 사항은 편집 내용으로 저장되며 원본 데이터는 변경되지 않습니다. 귀하의 예에서 건물은 처음에 공공 부문 데이터에서 들어옵니다. 사용자가 편집하면 변경 또는 차이가 별도의 테이블에 저장됩니다. 누군가 기능을 볼 때 원본과 수정 사항이 적용됩니다. 후속 편집은 새로운 피처 형태와 원본과 이전의 모든 편집 사이의 계산 된 차이입니다.

이를 통해 세밀한 수준에서 실행 취소 할 수 있습니다. 본질적으로 버전 관리가하는 일입니다. 비파괴적인 편집의 좋은 예는 Apple의 Aperture입니다. Aperture에서 가져온 디지털 이미지는 직접 수정되지 않습니다. 레벨 변경, 선명 화, 흐림 등은 편집 작업으로 저장되며 이미지 작업시 즉시 적용됩니다. 모든 변경 사항을 즉시 제거 할 수 있습니다.

물론 프로덕션 환경에서의 배포 및 사용을 위해 DB의 스냅 샷을 작성합니다. 이것은 개발과 편집에만 해당됩니다.

아이디어와 가능한 해결책 은 Versioning PostGIS , pgVersion 및 Post Facto 를 살펴보십시오 . 이들은 PostgreSQL 데이터베이스에 구현 된 버전 관리 시스템입니다.

OSM은 Postgres 및 Postgis를 사용하여 데이터베이스의 스냅 샷을 유지합니다.

자신의 서버 및 데이터베이스에서이를 구현하려면

http://wiki.openstreetmap.org/wiki/Databases#Choice_of_DBMS

데이터베이스 (plantet.osm)는 매주 업데이트됩니다. http://wiki.openstreetmap.org/wiki/Planet_dump

삼투 는"데이터베이스 및 파일에서 읽기위한 구성 요소, 데이터베이스 및 파일에서 쓰기위한 구성 요소, 데이터 소스에 변경 세트를 가져오고 적용하기위한 구성 요소가 있습니다"

http://wiki.openstreetmap.org/wiki/Osmosis

창 세트 : http://wiki.openstreetmap.org/wiki/Osmosis/Detailed_Usage#Changeset_Derivation_and_Merging

나는이 문제에 대해 생각했지만 아이디어가 있었지만 테스트하지는 않았습니다. 작동 할 수 있습니다 :

Mercurial 또는 Git과 같은 버전 제어 시스템을 사용하십시오. 익명의 브랜치를 쉽게 만들 수 있기 때문에 Mercurial이 더 쉬울 것입니다.

이제 초기 개정부터 공개 데이터 세트 가져 오기를위한 분기를 시작하십시오. 따라서 두 가지가 있습니다.

1. 메인 라인 (OSM)
2. 공개 데이터 세트 X

퍼블릭 데이터 세트에서 가져 오기는 브랜치 2에서 수행 한 다음 OSM 브랜치로 병합해야합니다.

시나리오는 다음과 같이 작동 할 수 있습니다.

• 개체가 존재하지 않았다
• 그런 다음 가져 오기 및 분기 1로 병합
• 그런 다음 지오메트리를 포함하여 메인 라인에서 수정됩니다.
• 지점 2에서 다시 가져옵니다.
• 지점 1에 병합되면 지점 2에서 업데이트 된 데이터 만 지점 1에서 업데이트됩니다.

이를 위해서는 데이터를 객체 당 하나씩 여러 파일로 분할하고 아마도 json과 같은 형식으로 분할해야하므로 VCS가 별도의 속성 변경을 쉽게 처리 할 수 ​​있습니다.

{
     id: 1357
     lat: 1,
     lon: 2,
     tags: {
          'building': 'entrance'
     }
     type: 'node',
}
{
     nodes: [
         1357,
         2468
     ],
     tags: {
         building: 'yes',
     }
     type: 'way',
}

정보를 10 억 개의 파일로 나누는 것이 어떤 시스템에도 너무 많은 것임을 알고 있습니다. 대신 VCS의 핵심을 사용해야하고 OSM 데이터를 버전 화 가능한 형식으로 VCS에 처리하고 제공해야합니다. 또는 파일 시스템을 조롱 할 수 있습니다.

이것이 작동한다고 보장 할 수 없습니다.