Làm thế nào để đối phó với phiên bản trong OpenStreetMap?

Chủ đề quản lý dữ liệu không gian địa lý theo nghĩa tổng quát hơn đã xuất hiện trước đây. Chủ đề của phiên bản cũng được đề cập ở đó, nhưng không thực sự được giải quyết.

Thu thập và bảo trì dữ liệu không gian địa lý truyền thống chỉ cần xử lý phiên bản nội bộ, vì cơ sở dữ liệu chỉ được cập nhật từ bên trong tổ chức. Đây không phải là trường hợp trong cơ sở dữ liệu địa lý đông người như OpenStreetMap. Ở đó, bất cứ ai cũng có thể đi cùng và thêm, sửa đổi hoặc xóa các đối tượng. Trong OpenStreetMap, điều này được xử lý theo cách thô sơ: mỗi đối tượng có số phiên bản nguyên và chỉ có đối tượng có phiên bản cao nhất được hiển thị trong cơ sở dữ liệu trực tiếp. Cơ sở dữ liệu sử dụng khóa tối ưu, vì vậy người dùng phải giải quyết tất cả các xung đột xảy ra khi tải lên các đóng góp theo cách thủ công.

Tất cả điều này hoạt động hợp lý miễn là đóng góp của con người thông qua các biên tập viên ( JOSM , Potlatch ) là phương thức đóng góp duy nhất - nhưng chúng không. Ngày càng tăng, nhập khẩu dữ liệu khu vực công mở được tiến hành. Chúng làm cho các vấn đề phiên bản phức tạp hơn. Hãy xem xét kịch bản sau đây:

1. Một đối tượng xây dựng đang được nhập từ bộ dữ liệu khu vực công cộng mở
2. Tòa nhà nhận được một số sửa đổi bởi những người đóng góp (thuộc tính, hình học hoặc cả hai)
3. Một phiên bản mới của dữ liệu khu vực công trở nên có sẵn và được nhập khẩu.

Hiện tại, trong bước 3. các đóng góp của con người sẽ bị mất, trừ khi mỗi tòa nhà nhận được sửa đổi cộng đồng được kết hợp thủ công với nhập mới.

Làm thế nào OpenStreetMap có thể đối phó với tình huống này? Chúng ta có cần xem xét kiểm soát phiên bản phân tán trong phát triển phần mềm không? Làm thế nào các phương pháp của DVC có thể được điều chỉnh để đối phó với bảo trì dữ liệu không gian phân tán?

Tôi đã mơ ước có ai đó thực hiện chỉnh sửa không phá hủy dữ liệu GIS. Nó tính toán chuyên sâu nhưng không nên thực hiện khó khăn trong RDBMS.

Bắt đầu với một ảnh chụp nhanh của dữ liệu. Mọi thay đổi được lưu dưới dạng chỉnh sửa, dữ liệu gốc không thay đổi. Trong ví dụ của bạn, các tòa nhà ban đầu đến từ dữ liệu của khu vực công. Khi người dùng thực hiện chỉnh sửa, thay đổi hoặc khác biệt sẽ được lưu trong một bảng riêng biệt. Khi ai đó xem tính năng, họ sẽ được cung cấp bản gốc cộng với mọi chỉnh sửa được áp dụng. Các chỉnh sửa tiếp theo là sự khác biệt được tính toán giữa hình dạng tính năng mới và bản gốc cộng với tất cả các chỉnh sửa trước đó.

Điều này cung cấp cho bạn khả năng hoàn tác ở mức độ chi tiết tốt. Nó là cơ bản những gì kiểm soát phiên bản làm. Một ví dụ điển hình về chỉnh sửa không phá hủy là Aperture của Apple. Hình ảnh kỹ thuật số nhập khẩu trong Aperture không được sửa đổi trực tiếp. Thay đổi về mức độ, độ sắc nét, độ mờ, v.v. được lưu trữ dưới dạng chỉnh sửa và được áp dụng nhanh chóng khi bạn làm việc với một hình ảnh. Bất kỳ thay đổi có thể được loại bỏ ngay lập tức.

Tất nhiên, bạn sẽ chụp ảnh DB để phân phối và sử dụng trong môi trường sản xuất. Điều này sẽ chỉ dành cho phát triển và chỉnh sửa.

Hãy xem Phiên bản PostGIS , pgVersion và Post Facto để biết ý tưởng và giải pháp khả thi. Đây là các hệ thống kiểm soát phiên bản được triển khai trong cơ sở dữ liệu PostgreQuery.

OSM sử dụng Postgres và Postgis để giữ ảnh chụp nhanh cơ sở dữ liệu.

Để thực hiện điều này trên máy chủ và cơ sở dữ liệu của riêng bạn

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

Cơ sở dữ liệu (plantet.osm) được cập nhật hàng tuần http://wiki.openstreetmap.org/wiki/Planet_dump

Thẩm thấu được sử dụng để"nó có các thành phần để đọc từ cơ sở dữ liệu và từ tệp, các thành phần để ghi vào cơ sở dữ liệu và tệp, các thành phần để lấy và áp dụng các bộ thay đổi cho nguồn dữ liệu"

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

Thay đổi: http://wiki.openstreetmap.org/wiki/Osmosis/Detailed_Usage#Changeset_Derivation_and_Merging

Tôi mặc dù vấn đề này và đã có một ý tưởng, nhưng không thử nghiệm nó. Có thể đấy:

Sử dụng hệ thống kiểm soát phiên bản như Mercurial hoặc Git. Mercurial sẽ dễ dàng hơn, vì nó cho phép dễ dàng tạo các nhánh ẩn danh.

Bây giờ, từ sửa đổi ban đầu, bắt đầu một chi nhánh cho nhập dữ liệu công khai. Vì vậy, sẽ có 2 chi nhánh:

1. tuyến chính (OSM)
2. dữ liệu công khai X

Việc nhập từ bộ dữ liệu công khai nên được thực hiện trong nhánh 2, sau đó được sáp nhập vào nhánh OSM.

Kịch bản của bạn có thể hoạt động như thế này:

• một đối tượng không tồn tại
• sau đó nó được nhập và sáp nhập vào chi nhánh 1
• sau đó nó được sửa đổi trong dòng chính, bao gồm cả hình học
• nó được nhập lại ở chi nhánh 2
• Khi nó được hợp nhất vào nhánh 1, chỉ có dữ liệu được cập nhật ở nhánh 2 được cập nhật ở nhánh 1

Điều này có thể yêu cầu chia dữ liệu thành nhiều tệp, mỗi tệp cho một đối tượng và có thể thành định dạng như json, để VCS có thể dễ dàng xử lý các thay đổi đối với các thuộc tính riêng biệt.

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

Tôi biết rằng việc chia thông tin trong một tỷ tệp là quá nhiều cho bất kỳ hệ thống nào. Thay vào đó, lõi của VCS nên được sử dụng và dữ liệu OSM nên được xử lý và đưa vào VCS ở dạng có thể phiên bản. (Hoặc một hệ thống tập tin có thể bị chế giễu).

Tôi không thể đảm bảo điều này sẽ làm việc.