การใช้ระบบควบคุมเวอร์ชันสำหรับข้อมูลเชิงพื้นที่? [ปิด]

ไม่ใช่ว่าฉันต้องการคำตอบที่ถูกต้องทันที แต่เมื่อเร็ว ๆ นี้ฉันได้เห็นความพยายามที่จะแนะนำแนวคิดของ "ระบบการควบคุมเวอร์ชัน" แบบกระจาย) "สำหรับข้อมูลทางภูมิศาสตร์ ตัวอย่างบางส่วน (ที่ฉันรู้) เป็นเอกสารสีขาวสามเล่มจาก OpenGeo ( 1 , 2 & 3 ) และโครงการ " Geosynkronisering (geosyncronization)" โดยผู้จำหน่ายซอฟต์แวร์ GIS นอร์เวย์และสำนักงานแผนที่นอร์เวย์ ฉันยังพบการกระจายข้อมูลเชิงพื้นที่ของรุ่นหรือไม่ ซึ่งระบุถึง GeoGit (โดย OpenGeo) และการใช้การควบคุมเวอร์ชันกับรุ่น ArcGIS ModelBuilder เกี่ยวกับการควบคุมเวอร์ชันใน ArcGIS

การเป็นนักพัฒนาฉันรู้ (อย่างน้อยก็พอที่จะใช้พวกเขา) วิธีที่ระบบควบคุมเวอร์ชันสำหรับซอร์สโค้ด (เช่น SVN และ Git) ทำงานได้และภูมิหลังของฉันในด้านธรณีศาสตร์บอกฉันว่ามีความท้าทายที่ไม่เหมือนใครกับข้อมูลทางภูมิศาสตร์ วิธีการไม่คล้ายกับวิธีซอร์สโค้ด (ซึ่งโดยทั่วไปคือข้อความ) ได้รับการจัดการ

อะไรคือความท้าทายเมื่อต้องรับมือกับ (VC) VCS'es สำหรับข้อมูลทางภูมิศาสตร์คุณจะแก้ปัญหาอย่างไรเราต้องการพวกเขาและมีความพยายามอื่น ๆ ในการแก้ไขปัญหาเหล่านี้มากกว่าที่ฉันได้กล่าวถึงไปแล้ว?

ฉันรู้ว่าสมุดปกขาว OpenGeo จะตอบคำถามของฉัน แต่สิ่งที่ฉันเป็นจริงหลังจากนั้นคือคำตอบ "pedagogical" ที่มากขึ้นในรูปแบบของ "บอกฉันว่าฉันอายุ 10 ขวบ" ฉันสามารถอ้างอิงผู้คนถึงคำอธิบายที่ดีของความท้าทายและการแก้ปัญหาที่ข้อมูลทางภูมิศาสตร์นำมาซึ่งการผสมผสาน

ฉันหวังว่าคนที่มีความเข้าใจลึกซึ้งจะใช้เวลาในการคิดบางอย่างเกี่ยวกับเรื่องนี้เพราะฉันบอกว่าตอนนี้ฉันไม่ได้กำลังมองหาที่จะแก้ปัญหาเฉพาะ แต่หัวข้อนี้เป็นหัวข้อที่ฉันสนใจ

ขณะนี้เรากำลังทำงานเกี่ยวกับการออกแบบที่สมบูรณ์ของ geodatastores ของเรา ฉันต้องบอกว่าวิวัฒนาการของพวกเขาใช้เวลามากกว่า 20 ปีจนถึงปัจจุบัน เราระบุคุณสมบัติสำคัญดังต่อไปนี้ในการจัดการข้อมูลเชิงพื้นที่:

• การแก้ไขพร้อมกัน
• สิทธิ์ในการอ่านหรือเขียนบางส่วนของข้อมูล
• hot update ขณะที่เรียกใช้บริการที่ต้องพึ่งพาข้อมูล (Transaction และกระบวนทัศน์ ACID)
• สคีมาภายในและภายนอก (การแก้ไขสคีมาภายในไม่ควรส่งผลกระทบต่อบริการ)
• ความสามารถในการจัดเก็บและเข้าถึงข้อมูลจำนวนมาก (เทราไบต์ของแรสเตอร์และ hundrets ของกิกะไบต์ของข้อมูลเวกเตอร์)
• ความสอดคล้องของข้อมูลระหว่างเลเยอร์ที่แตกต่างกัน (ทุกพัสดุเป็นของอำเภอและอื่น ๆ )

เราประเมินวิธีการต่อไปนี้นี่คือสิ่งที่ฉันสามารถพูดเกี่ยวกับพวกเขา:

1. ESRI Enterprise Geodatabase(ArcGIS 10.1); ค่อนข้างเหมือนกับสิ่งที่เรามีมาก่อน (SDE) แต่ด้วยการใช้คุณสมบัติการกำหนดเวอร์ชันอย่างกว้างขวางเพื่อจัดการธุรกรรม แต่มันไม่ใช่ฐานข้อมูลองค์กรจริง ๆ ในความคิดของฉัน SDE ใช้งานได้ในเวิร์กกรุ๊ปเป็นเซิร์ฟเวอร์ geodata ซึ่งผู้คนทำงานตั้งแต่ 8:00 น. ถึง 20:00 น. และคุณสามารถออฟไลน์ได้สำหรับงานบำรุงรักษา ทรานแซกชันที่ให้คำปรึกษา (การกำหนดเวอร์ชันกระทบยอดและโพสต์ในคำพูดของ ESRI), การจำลองแบบ, ฯลฯ ... ถ้าคุณสร้างบริการที่อยู่ด้านบนของข้อมูลนี้คุณจะต้องจัดการฐานข้อมูลการแสดงละคร มันค่อนข้างเหมือนกันกับ build / test และปรับใช้ในการเขียนโปรแกรม แม้ว่าฟีเจอร์ที่สมบูรณ์ของแพ็คเกจ ESRI นั้นค่อนข้างดี แต่มันก็ไม่มีความยืดหยุ่น (การเปลี่ยนแปลงสคีมาหรืองานบำรุงรักษาในขณะที่ผู้คนกำลังทำงานการสร้างดัชนีเป็นต้น)

2. ไฟล์แบนและระบบควบคุมเวอร์ชันเราเลือก Git (ไม่รู้ว่ามี GeoGit อยู่แล้ว) ใช่แล้วเพื่อนของฉันและตัวฉันเองบางคนก็มาจากวิศวกรรมซอฟต์แวร์ด้วย มันอาจจะง่ายมาก ฉันคิดว่านั่นเป็นปัญหา: มันเหมือนกับช่างซ่อมรถยนต์ที่สร้างรถยนต์ มันจะง่ายต่อการบำรุงรักษาสำหรับเขา แต่มันก็น่ารำคาญที่จะขับรถและดูน่าเกลียดน่าดู ฉันคิดว่ามันยังมีข้อเสียที่สำคัญบางประการ: วิธีควบคุมเวอร์ชัน 2 TeraByte (หรือมากกว่านั้น) ไบนารี Rasterdataset? และรูปแบบไหน ข้อมูลเวกเตอร์สามารถควบคุมเวอร์ชันได้อย่างง่ายดายหากคุณใช้รูปแบบ textbased (ตัวอย่างเช่น GML) แต่ก็ยากที่จะทำงานกับชุดข้อมูลนับพันล้านแถวได้ ฉันยังไม่แน่ใจว่าเราสามารถจัดการสิทธิ์ผู้ใช้ได้อย่างมีประสิทธิภาพหรือไม่เพราะทุกคนไม่ควรได้รับอนุญาตให้แก้ไขหรือดูทุกอย่าง และคุณจะรวมชุดข้อมูลเวกเตอร์ที่แก้ไขโดยผู้ใช้ 4 คนในเวลาเดียวกันได้อย่างไร อย่างน้อยคุณก็ต้องเป็นนักวิทยาศาสตร์คอมพิวเตอร์ / โปรแกรมเมอร์จริง ๆ ที่จะทำสิ่งนี้ได้อย่างมีประสิทธิภาพ ... ผู้ใช้ GIS ของเราคือนักวางแผนนักสำรวจธรณีวิทยาและอื่น ๆ มันเป็นปัญหาสำหรับพวกเขาที่จะนึกถึงเชื้อสายเวอร์ชั่นเช่นโปรแกรมเมอร์ทำหรือใช้วิธีการแยกสาขาตามที่ควรจะเป็น อย่างไรก็ตามการคิดถึงดาต้าสโตร์เป็น repos ที่แชร์เป็นแนวคิดที่น่าสนใจ

3. ฐานข้อมูลที่แบนราบเป็นภาชนะง่าย เช่นเดียวกับ SDE ทำ แต่ไม่มี SDE ยังคงรักษาได้ยากเพราะคุณไม่ได้ใช้ประโยชน์จากข้อดีที่ RDBMS เสนอให้คุณ ใช่ง่ายมากเพียงแค่โหลดทุกอย่างในฐานข้อมูล แต่นั่นไม่ใช่การจัดการข้อมูลเลย

4. BigData และ NoSQL ปัญหาเช่นเดียวกับไฟล์แบนและตารางแบน ในความคิดของฉัน API ระบบไฟล์ที่เรียบง่ายสำหรับใช้ในเว็บ ใช่มันทำงานได้ดีในเว็บและใช่มันง่ายที่จะเพียงแค่โยนเอกสารของคุณใน แต่ฉันคิดว่าถ้าฉันต้องการที่จะวิเคราะห์ข้อมูลเชิงพื้นที่บนเทราไบต์ของข้อมูล (อาจแรสเตอร์) ฉันชอบที่จะไม่ทำให้มันเป็นอนุกรมและ deserialized ผ่านอินเตอร์เฟส HTTP

UPDATE 2018: นี่คือสิ่งใหม่มากมายที่สร้างแรงผลักดันมากมาย หากต้องการตั้งชื่อไม่กี่:

• ที่เก็บข้อมูลบนคลาวด์บล็อกและ HDFS
• Python / shapely / Dask Stack

• Apache Spark

  • GeoMesa / GeoWave สำหรับข้อมูลเวกเตอร์
  • GeoTrellis สำหรับข้อมูลแรสเตอร์

• และอีกมากมาย

  5. การสร้างแบบจำลองฐานข้อมูลคลาสสิกที่ครอบคลุม(ด้วย RDBMS) ปัญหาหลักคือมันยากที่จะทิ้งข้อมูลได้ทุกที่และหวังว่ามันจะเหมาะกับทุกความต้องการในอนาคต แต่ถ้าคุณใช้เวลาในการระบุ datamodel ที่มีประสิทธิภาพ (OSM ก็ทำเช่นนี้ด้วย) ในฐานข้อมูลคุณสามารถใช้ประโยชน์จากข้อดีทั้งหมดได้ เราสามารถแก้ไขและอัปเดตข้อมูลในธุรกรรมแบบกระจายเรายังสามารถแก้ไขสคีมาหลักของพวกเขาในขณะที่บริการยังคงพึ่งพาสคีมาภายนอกของข้อมูลเดียวกันเราสามารถรักษามันไว้ได้เราสามารถตรวจสอบความสอดคล้องของมันเราสามารถตรวจสอบความสอดคล้อง สามารถจัดเก็บข้อมูลจำนวนมากในขณะที่เรายังสามารถเข้าถึงข้อมูลได้อย่างรวดเร็วเราสามารถสร้างดาตาโมเดลที่มีประวัติมาแล้วและทริกเกอร์มันได้อย่างโปร่งใสเป็นต้น เนื่องจากเราใช้เซิร์ฟเวอร์ sql เรายังคงมีประเภทแรสเตอร์ดั้งเดิมอยู่ แต่ผู้ค้าฐานข้อมูลรายอื่นเสนอสิ่งนี้แล้ว

ฉันคิดว่ารูปแบบฐานข้อมูลเชิงสัมพันธ์เพิ่งจะเกิดขึ้นในโลกอวกาศด้วยประเภทข้อมูลเชิงพื้นที่ในช่วงสองสามปีที่ผ่านมา (ก่อนหน้านั้นคือที่ที่บรรจุ BLOB) และยังคงเป็นรูปแบบการจัดเก็บข้อมูลที่ยืดหยุ่นและเป็นมืออาชีพมากที่สุด ไม่ได้หมายความว่าไม่ควรเสริมด้วยแนวทาง VCS หรือ NoSQL แต่ฉันเห็นว่าวิธีการเหล่านี้มีแนวโน้มที่จะเป็นรูปแบบของการกระจายข้อมูลในกลุ่มผู้ใช้มากกว่ารูปแบบของการจัดการข้อมูลเชิงพื้นที่จากศูนย์กลางแบบมืออาชีพ เช่นเดียวกันกับการนำเข้าข้อมูลจำนวนมาก (ข้อมูล OSM ส่วนใหญ่ในออสเตรียถูกนำเข้ามาในหนึ่งวันไม่ใช่การระดมทุน) และการสร้างไทล์ ส่วนการทำงานร่วมกัน (การจัดหาผู้คน) นั้นสำคัญมาก แต่เป็นเพียงครึ่งเดียวของธุรกิจ

ฉันคิดว่าฉันจะต้องใช้ถ้อยคำนี้ให้มากและให้ข้อเท็จจริงเพิ่มเติม คำถามเช่นนี้ยากที่จะตอบอย่างครอบคลุมในสองสามชั่วโมงฉันจะพยายามปรับปรุงคุณภาพของคำตอบของฉันในวันถัดไป