การจัดการข้อมูลเชิงพื้นที่จำนวนมาก? [ปิด]

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

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

ฉันคิดว่าคำตอบหุ้น / ที่เห็นได้ชัดคือการใช้ฐานข้อมูลเชิงพื้นที่ (PostGIS, Oracle, SDE, MSSQL Spatial และอื่น ๆ ) ร่วมกับเซิร์ฟเวอร์ข้อมูลเมตาเช่น GeoPortal หรือแอปพลิเคชัน GeoNetwork ของโอเพ่นซอร์สโดยรวม ทางออกที่ดีที่สุด อย่างไรก็ตามคุณอาจมีความต้องการสแน็ปช็อต / สาขา / แท็กตามโครงการเสมอ ฐานข้อมูลขั้นสูงบางส่วนมีวิธีการจัดการเหล่านี้ แต่โดยทั่วไปไม่ได้ง่ายสำหรับผู้ใช้ / จัดการ

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

ฉันได้เห็นวิธีแก้ปัญหาที่น่าสนใจแล้ว ...

ย้อนกลับไปเมื่อกระทรวงสิ่งแวดล้อมของ BC กำลังปิดการทำงานของอาร์ค / ข้อมูลพวกเขามีกระบวนการซิงโครไนซ์แบบสองทางที่ใช้งานได้ดี ความครอบคลุมที่อยู่ภายใต้การควบคุมส่วนกลางถูกผลักออกไปยังภูมิภาคทุกคืนและข้อมูลภูมิภาคถูกส่งกลับเข้ามาการถ่ายโอนความแตกต่างระดับบล็อกนี้ทำได้ดีมากแม้จะเชื่อมโยงมากกว่า 56k มีกระบวนการที่คล้ายกันสำหรับการเรพลิเคทฐานข้อมูลแอ็ตทริบิวต์ที่ใช้ Oracle แต่ฉันไม่คิดว่าพวกเขาโดยทั่วไปจะทำการโทรผ่านสายโทรศัพท์ได้ดีเกินไป :)

ที่ทำงานปัจจุบันของฉันใช้โซลูชันไฮบริดที่คล้ายกัน ชุดข้อมูลแต่ละชุดมีสำเนาที่เชื่อถือได้ (บางส่วนใน Oracle, อื่น ๆ ใน MapInfo, อื่น ๆ ในฐานข้อมูลส่วนบุคคลทางภูมิศาสตร์) และเหล่านี้เป็นแบบข้าม ETL ทุกคืนโดยใช้ FME มีบางค่าใช้จ่ายที่สำคัญสวยที่นี่เมื่อมันมาถึงการบำรุงรักษาแม้ว่า; ความพยายามในการสร้างชุดข้อมูลใหม่และตรวจสอบให้แน่ใจว่าทัศนวิสัยขององค์กรสูงกว่าที่ควรจะเป็น เราอยู่ในระหว่างการตรวจสอบเพื่อหาวิธีการรวมบัญชีเพื่อหลีกเลี่ยงค่าใช้จ่ายนี้

ข้อมูลเมตาเป็นปัญหาที่สำคัญที่สุดที่นี่ หากข้อมูลเมตาตอบคำถามว่าใครคือใครเมื่อใดทำไมจึงเป็นระเบียนเมตาดาต้าที่ยอมรับได้

การมีประสบการณ์การทำงานใน บริษัท ขนาดใหญ่ที่มีผู้ใช้ GIS เพียงไม่กี่คน (ประมาณ 30 คน) เรามีปัญหาสำคัญในการควบคุมข้อมูลรุ่นพิเศษและการอนุญาต ด้านหนึ่งของสิ่งนี้สามารถแก้ไขได้ด้วยการจัดทำเอกสารของข้อมูล (ข้อมูลเมตา) และปัญหาอื่น ๆ มักแก้ไขได้ด้วยที่เก็บส่วนกลางซึ่ง PostGIS ส่องสว่าง

GeoNetwork เป็นการเริ่มต้นที่ดีในการจัดการปัญหาเมตาดาต้า การแก้ไขที่เก็บส่วนกลางมีความซับซ้อนมากขึ้นเนื่องจากอาจต้องใช้คนพิเศษในการออกแบบ / บำรุงรักษาฐานข้อมูล

ปัญหาที่ซับซ้อนคือใครจะรับผิดชอบ QA / QC ชุดข้อมูลเหล่านี้และข้อมูลเมตาของพวกเขา แม้ว่ากระบวนการที่ขับเคลื่อนด้วยคอมพิวเตอร์จะทำงานได้ดี แต่พวกเขาก็ไม่สามารถเข้มงวดได้เหมือนผู้จัดการข้อมูล / ผู้รักษาข้อมูลที่ดีซึ่งเกิดขึ้นใน บริษัท นี้ที่ฉันทำงาน ขณะนี้มีบางคนอยู่ที่นั่นเพื่อตรวจสอบ / ส่งเมทาดาทาและจัดระเบียบข้อมูลเชิงพื้นที่ที่ไม่ได้รวมศูนย์ไว้ใน DBMS

เราใช้ระบบไฟล์ที่จัดเรียงตามลำดับชั้นโดย: - ขอบเขตทางภูมิศาสตร์ (ประเทศหรือทวีป) - ผู้ให้บริการข้อมูลผู้ให้อนุญาต - โดเมน / ชุดข้อมูล - วันที่ / รุ่น

หลังจากนั้นเรามีนโยบายที่จะแยกแหล่งข้อมูล (ในรูปแบบเดียวกับที่อยู่ในแผ่นซีดี / ดีวีดีใดก็ตามที่เราได้รับจากผู้ให้บริการ) จากชุดข้อมูลใด ๆ ที่เราได้รับภายใน บริษัท ของเรา

ระบบไฟล์ทำให้ง่ายต่อการนำเข้าข้อมูลใด ๆ จากลูกค้าและยังช่วยให้มีความยืดหยุ่นในแง่ของการจัดเก็บทางกายภาพ - เราเก็บแฟ้มเก็บถาวรของเราไว้ในดิสก์ที่ใหญ่กว่าช้าลงและเรามีเซิร์ฟเวอร์ไฟล์พิเศษ ชุดข้อมูลที่ใช้บ่อยขึ้น

เพื่ออำนวยความสะดวกในการจัดการภายในโครงการเราใช้ลิงก์สัญลักษณ์ เราเก็บพาหะของเราไว้ในฐานข้อมูล (Oracle) และเรากำหนดเป็นกฎให้มีอินสแตนซ์ฐานข้อมูลอย่างน้อยหนึ่งรายการต่อลูกค้า (และผู้ใช้ / สคีมาหลายโครงการสำหรับโครงการ) เราไม่ได้เก็บ rasters จำนวนมากไว้ในฐานข้อมูลเนื่องจากมีแนวโน้มที่จะใช้พื้นที่มากเกินไปแม้จะอยู่นอก นอกจากนี้เราต้องการให้อินสแตนซ์ฐานข้อมูลของเรามีน้ำหนักเบาที่สุดเท่าที่จะทำได้

และใช่เรามีใครบางคนในการดูแล 'เรื่องทั้งหมด' ดังนั้นมันจึงไม่ยุ่งเกินไป

ปัญหาที่ใหญ่ที่สุดที่เรามีกับการตั้งค่านี้ในปัจจุบันคือการขาดอินเทอร์เฟซผู้ใช้ที่ดีซึ่งจะช่วยให้เรามีภาพรวมที่ดีขึ้นในทุกเรื่องและเราวางแผนที่จะรวมที่เก็บข้อมูลเมตา เรายังคงพิจารณาตัวเลือกของเราที่นี่

เราใช้การควบคุมเวอร์ชันสำหรับรหัสของเราและเราใช้มันกับเอกสาร แต่ปรากฎว่าการควบคุมเวอร์ชันไม่ได้ถูกสร้างขึ้นมาสำหรับชุดข้อมูลขนาดใหญ่โดยเฉพาะอย่างยิ่งถ้าพวกเขาส่วนใหญ่เป็นไฟล์ไบนารีดังนั้นฉันจึงไม่แนะนำ ยกเว้นว่าคุณกำลังติดต่อกับ GML หรือข้อความคล้าย ๆ กัน (ปัญหามีค่าใช้จ่ายจำนวนมากในการใช้ดิสก์ด้านเซิร์ฟเวอร์รวมถึงลูกค้าหยุดทำงานเมื่อตรวจสอบที่เก็บข้อมูลขนาดใหญ่)

@JasonBirch กล่าวว่าการควบคุมเวอร์ชันเป็นปัญหาใหญ่

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

นอกจากนี้หากคุณยังไม่เคยเห็นฉันแนะนำให้ดูที่การสื่อสารทางภูมิศาสตร์และการออกแบบข้อมูลโดย Lars Brodersen อย่างน้อยก็สำหรับสิ่งที่เขาพูดในการสร้างแบบจำลองข้อมูล

Postgres ทุกอย่างที่คนอื่นพูด แต่ถ้าคุณต้องการให้มันพกพาและเคลื่อนย้ายได้ง่ายคุณก็สามารถใช้ SQLite + ส่วนขยาย Spatialite ได้ตลอดเวลา

ไม่ใช่เรื่องง่ายที่จะใช้เป็น Postgres ในแง่ของเครื่องมือการจัดการ แต่ QGis สามารถพูดคุยโดยตรงกับฐานข้อมูล GIS ที่เปิดใช้งานเชิงพื้นที่โดยไม่มีปัญหาใด ๆ

จริง ๆ แล้วฉันใช้ SQLite + Spatialite สำหรับการสำรองข้อมูลฉันมีบริการ windows ที่ทำงานอยู่เบื้องหลัง

อีกหนึ่งเคล็ดลับด้วย PG ก็ใช้สกีมา

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

ตัวอย่างเช่นฐานข้อมูล "Ordnance_Survey" ของฉันมีสกีมาสำหรับ VectormapDistrict VectormapLocal Topo50 LookupGrids CodePointWithPolygons CodePointOpen

ที่ฉันเก็บข้อมูลที่เกี่ยวข้องทั้งหมด

ในขณะที่ตารางเมทาดาทาเช่นคอลัมน์รูปทรงเรขาคณิต ฯลฯ ทั้งหมดอยู่ในที่สาธารณะส่วนขยาย Postgis ยังเปิดใช้งานในสคีมาสาธารณะเท่านั้น แต่สามารถเข้าถึงได้จากสคีมาอื่น ๆ ที่ใช้งานอยู่

จากการโพสต์ก่อนหน้านี้กล่าวถึงฐานข้อมูลเชิงพื้นที่และเซิร์ฟเวอร์ข้อมูลเมตาคือการตั้งค่าปกติ ฉันคิดว่าสิ่งสำคัญที่ต้องจำคือ 'ขนาดเดียวไม่พอดีทั้งหมด' คุณจะจบลงด้วยข้อมูลที่เหมาะสมที่สุดใน Oracle, ไฟล์เซิร์ฟเวอร์, เซิร์ฟเวอร์ SQL หรืออะไรก็ตาม ฉันได้ลองใส่ข้อมูลทั้งหมดลงในโซลูชันเดียวและมักจะล้มเหลว

คาดว่าจะใช้โซลูชันที่แตกต่างที่เหมาะสมกับข้อมูลและวางแผนสำหรับพวกเขา นี่คือที่มาทางภูมิศาสตร์ (เซิร์ฟเวอร์ข้อมูลเมตา) เข้ามาจริงๆ

ฉันต้องเห็นด้วยกับ 'George' ข้างต้นว่าข้อมูลเมตาควรมีบทบาทสำคัญในการจัดการข้อมูลเชิงพื้นที่ จริง ๆ แล้วกับข้อมูลดิจิตอลใด ๆ เมตาดาต้าเป็นกุญแจสำคัญ - ลองนึกถึงช่างภาพที่พยายามจัดการไฟล์ภาพถ่ายดิจิทัลของเขาโดยไม่มีเมตาดาต้าที่เหมาะสม ชีวิตจะง่ายขึ้นมากถ้าคุณติดแท็กสิ่งต่าง ๆ อย่างเคร่งศาสนาและมีซอฟต์แวร์ที่ดีที่สามารถใช้ข้อมูลได้ ตอนนี้คำถามดั้งเดิมเกี่ยวกับ 'จัดการข้อมูลเชิงพื้นที่ทางภูมิศาสตร์' ค่อนข้างกว้าง - ซึ่งอาจเป็นรูปแบบข้อมูลที่จะเก็บไว้ในแบบแผนการตั้งชื่อลำดับชั้นของชุดข้อมูลและคุณสมบัติการแก้ไขบทบาทและสิทธิพิเศษ ฯลฯ เป็นต้น

รูปแบบการจัดเก็บข้อมูล geospatial ขึ้นอยู่กับวิธีที่คุณต้องการสืบค้น / สิ่งที่คุณต้องการจะทำกับมัน ต่อไปนี้เป็นเครื่องมือบางอย่างที่คุณสามารถพิจารณา:

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

MongoDB: สิ่งนี้รองรับข้อมูลจำนวนมาก เหมาะอย่างยิ่งสำหรับการจัดเก็บการสืบค้นและการสืบค้นเชิงภูมิศาสตร์แบบ จำกัด

พื้นที่จัดเก็บไฟล์: หากคุณเป็นเพียงระบบจัดเก็บข้อมูลและใช้เพียงบางส่วนของข้อมูลในการสืบค้นคุณอาจประหยัดในการจัดเก็บข้อมูลเป็นไฟล์ ข้อกำหนดการควบคุมเวอร์ชันของคุณอาจพอใจกับสิ่งนี้

Redis: คุณสามารถรวมตัวเลือกใด ๆ ข้างต้นเข้ากับการสนับสนุน Redis Geo เพื่อเก็บข้อมูล 'ร้อน' จำนวนเล็กน้อยใน redis ที่คุณต้องการเข้าถึงบ่อยครั้ง คิดว่านี่เป็นแคชของคุณ