Triển khai hệ thống kiểm soát phiên bản cho dữ liệu không gian địa lý? [đóng cửa]

Không phải là tôi đang cần một câu trả lời ngay tại đây, nhưng gần đây tôi đã thấy một số nỗ lực để giới thiệu khái niệm "hệ thống kiểm soát phiên bản (phân tán)" cho dữ liệu địa lý. Một số ví dụ (mà tôi biết) là ba trang trắng của OpenGeo ( 1 , 2 & 3 ) và dự án " Geosynkronisering (geosyncronization)" của các nhà cung cấp Phần mềm GIS Na Uy và Cơ quan Bản đồ Na Uy. Tôi cũng đã tìm thấy phiên bản phân tán của dữ liệu không gian địa lý? , trong đó đề cập đến GeoGit (bởi OpenGeo) và Áp dụng kiểm soát phiên bản cho các mô hình ArcGIS ModelBuilder? về kiểm soát phiên bản trong ArcGIS.

Là một nhà phát triển mà tôi biết (ít nhất là đủ để có thể sử dụng chúng) cách các hệ thống kiểm soát phiên bản cho mã nguồn (như SVN và Git) hoạt động, và nền tảng về địa chất học của tôi cho tôi biết rằng có một số thách thức duy nhất với dữ liệu địa lý tạo ra Cách tiếp cận không hoàn toàn tương tự như cách mã nguồn (về cơ bản là văn bản) được xử lý.

Những thách thức khi xử lý (d) VCS đối với dữ liệu địa lý là gì, bạn sẽ giải quyết chúng như thế nào, chúng ta có cần chúng không và có những nỗ lực nào khác để giải quyết những vấn đề này hơn những vấn đề tôi đã đề cập?

Tôi biết rằng các trang trắng OpenGeo sẽ trả lời một số câu hỏi của tôi, nhưng những gì tôi thực sự là sau đó là một câu trả lời "sư phạm" hơn, theo kiểu "nói với tôi như tôi là một đứa trẻ 10 tuổi", vì vậy mà Tôi có thể giới thiệu cho mọi người một lời giải thích tuyệt vời về những thách thức và giải pháp mà dữ liệu địa lý mang lại cho sự pha trộn.

Tôi hy vọng rằng ai đó có cái nhìn sâu sắc sẽ dành thời gian để đưa ra một vài suy nghĩ về vấn đề này, như tôi đã nói hiện tại tôi không muốn giải quyết một vấn đề cụ thể nào, nhưng chủ đề này là một vấn đề khiến tôi quan tâm.

Chúng tôi hiện đang làm việc để thiết kế lại hoàn toàn các geodatastores của chúng tôi. Tôi phải nói rằng sự tiến hóa của họ mất hơn 20 năm cho đến nay. Chúng tôi đã xác định các tính năng chính sau đây trong quản lý dữ liệu không gian địa lý:

• chỉnh sửa đồng thời
• quyền đọc hoặc ghi các phần dữ liệu
• cập nhật nóng trong khi chạy các dịch vụ dựa trên dữ liệu (Mô hình giao dịch và ACID)
• lược đồ bên trong và bên ngoài (sửa đổi lược đồ bên trong sẽ không ảnh hưởng đến các dịch vụ)
• khả năng lưu trữ và truy cập một lượng lớn dữ liệu (terabyte raster và vô số gigabyte dữ liệu vector)
• thống nhất dữ liệu giữa các lớp khác nhau (mỗi bưu kiện thuộc về một quận và vv)

Chúng tôi đã đánh giá các phương pháp sau đây, đây là những gì tôi có thể nói về chúng:

1. Cơ sở dữ liệu địa lý doanh nghiệp ESRI(ArcGIS 10.1); gần giống như những gì chúng ta đã có trước đây (SDE), nhưng với việc sử dụng rộng rãi tính năng tạo phiên bản để xử lý các giao dịch. Nhưng nó đơn giản không thực sự là Cơ sở dữ liệu địa lý doanh nghiệp, theo tôi, SDE chỉ hoạt động trong một nhóm làm việc như một máy chủ geodata, nơi mọi người làm việc từ 8:00 sáng đến 8:00 tối và sau đó bạn có thể mang nó ngoại tuyến cho các nhiệm vụ bảo trì, cam kết giao dịch (phiên bản đối chiếu và đăng trong bài phát biểu ESRI), sao chép, v.v ... Nếu bạn xây dựng các dịch vụ trên đầu dữ liệu này, bạn phải xử lý cơ sở dữ liệu phân tầng (nơi thực hiện công việc) một cơ sở dữ liệu sản xuất được sao chép. Điều này khá giống với xây dựng / kiểm tra và triển khai trong lập trình. Mặc dù gói giàu tính năng ESRI cung cấp khá đẹp, nhưng nó thiếu tính linh hoạt (thay đổi lược đồ hoặc nhiệm vụ bảo trì trong khi mọi người đang làm việc, ví dụ như tạo chỉ mục).

2. Tập tin phẳng và hệ thống kiểm soát phiên bảnchúng tôi chọn Git (Không biết rằng đã có GeoGit). Ồ vâng, một số bạn bè của tôi và bản thân tôi cũng đến từ công nghệ phần mềm. Tất cả có thể đơn giản như vậy. Tôi nghĩ đó là vấn đề của nó: Nó giống như một thợ sửa xe đang chế tạo một chiếc xe hơi. Nó sẽ đơn giản để duy trì cho anh ta, nhưng cũng sẽ gây khó chịu khi lái xe và xấu xí để nhìn vào chắc chắn. Tôi nghĩ rằng nó cũng có một số nhược điểm lớn: Làm thế nào để phiên bản kiểm soát Rasterdataset 2 TeraByte (hoặc thậm chí nhiều hơn, nhị phân)? Và ở định dạng nào? Dữ liệu vectơ có thể được kiểm soát phiên bản dễ dàng nếu bạn sử dụng các định dạng dựa trên văn bản (ví dụ GML), nhưng cũng khó để làm việc với một tỷ dữ liệu hàng sau đó. Tôi vẫn không chắc chắn liệu chúng ta có thể quản lý quyền người dùng hiệu quả hay không, bởi vì không phải ai cũng được phép chỉnh sửa hoặc thậm chí xem mọi thứ. Và làm thế nào để bạn hợp nhất một tập dữ liệu vector được chỉnh sửa chuyên sâu bởi 4 người dùng cùng một lúc? Ít nhất bạn phải là một nhà khoa học / lập trình viên máy tính thực thụ để thực hiện tất cả những điều này một cách hiệu quả ... người dùng GIS của chúng tôi là những người lập kế hoạch, khảo sát, nhà địa chất, v.v. Đơn giản là vấn đề khiến họ nghĩ về các dòng phiên bản giống như các lập trình viên thường làm hoặc sử dụng phân nhánh theo cách mà nó được yêu cầu. Tuy nhiên, nghĩ về kho dữ liệu như là repos chia sẻ là một ý tưởng thú vị.

3. Cơ sở dữ liệu theo bảng phẳng như một container đơn giản. Giống như SDE làm điều đó, nhưng không có công cụ SDE. Vẫn khó duy trì, vì bạn thực sự không tận dụng những lợi thế mà RDBMS mang lại cho bạn. Có, nó rất đơn giản để chỉ tải mọi thứ trong cơ sở dữ liệu, nhưng đó không phải là quản lý dữ liệu.

4. Bigdata và NoQuery . Các vấn đề tương tự như các tập tin phẳng và bảng phẳng. Theo tôi, API hệ thống tập tin đơn giản để sử dụng trên web. Có, nó hoạt động tốt trên web và có thể dễ dàng ném tài liệu của bạn vào, nhưng tôi nghĩ rằng nếu tôi muốn thực hiện phân tích dữ liệu không gian trên terabyte dữ liệu (có thể là raster), tôi muốn nó không bị tuần tự hóa và giải tuần tự qua giao diện HTTP.

CẬP NHẬT 2018: Dưới đây là rất nhiều thứ mới tạo ra rất nhiều động lực. Đến tên một vài:

• Lưu trữ khối đám mây và HDFS
• Python / shapely / Dask Stack

• Spark Spark

  • GeoMesa / GeoWave cho dữ liệu Vector
  • GeoTrellis cho dữ liệu raster

• và nhiều hơn nữa

  5. Mô hình cơ sở dữ liệu cổ điển toàn diện(với RDBMS). Vấn đề chính là, thật khó để bỏ dữ liệu vào bất cứ đâu và hy vọng rằng nó phù hợp với mọi nhu cầu trong tương lai. Nhưng nếu bạn dành một lượng thời gian để chỉ định một kiểu dữ liệu mạnh mẽ (OSM cũng thực hiện điều này trên thực tế) trong cơ sở dữ liệu, bạn có thể sử dụng tất cả các lợi thế của nó. Chúng tôi có thể chỉnh sửa và cập nhật dữ liệu trong các giao dịch phân tán, chúng tôi cũng có thể sửa đổi lược đồ cốt lõi của chúng, trong khi các dịch vụ vẫn dựa trên các lược đồ bên ngoài của cùng một dữ liệu, chúng tôi có thể duy trì dữ liệu đó, chúng tôi có thể kiểm tra tính nhất quán của nó, chúng tôi có thể cho phép và từ chối cấp phép có thể lưu trữ một lượng lớn dữ liệu trong khi chúng ta vẫn có thể truy cập nó một cách nhanh chóng, chúng ta có thể xây dựng các bảng dữ liệu lịch sử và kích hoạt nó một cách minh bạch và cứ thế. Bởi vì chúng tôi sử dụng máy chủ sql, chúng tôi vẫn thiếu một loại raster bản địa, nhưng các nhà cung cấp cơ sở dữ liệu khác đã cung cấp điều này.

Vâng, tôi nghĩ rằng mô hình cơ sở dữ liệu quan hệ chỉ xuất hiện trong thế giới không gian với các kiểu dữ liệu không gian trong vài năm qua (trước đó là BLOB Container) và vẫn là hình thức lưu trữ dữ liệu linh hoạt và chuyên nghiệp nhất. Điều đó không có nghĩa là không nên bổ sung các cách tiếp cận VCS hoặc NoQuery nhưng tôi thấy các cách tiếp cận này có nhiều khả năng là một hình thức phân phối dữ liệu trong các nhóm người dùng hơn là một hình thức quản lý dữ liệu không gian tập trung chuyên nghiệp. Ngoài ra OSM đã tập trung rất nhiều nhiệm vụ mà đám đông không thể cung cấp, như nhập một lượng lớn dữ liệu (hầu hết dữ liệu OSM ở Áo được nhập trong một ngày, không phải đám đông) và tạo gạch. Phần hợp tác (tìm nguồn cung ứng đám đông) thực sự rất quan trọng, nhưng nó chỉ là một nửa doanh nghiệp.

Tôi nghĩ rằng tôi phải viết lại rất nhiều điều này và cung cấp thêm sự thật. Một câu hỏi như thế này rất khó để trả lời toàn diện trong một vài giờ, tôi sẽ cố gắng cải thiện chất lượng câu trả lời của mình vào những ngày tiếp theo