บริษัท ของฉันใช้geometry( the_geom) ชนิดข้อมูลเพื่อจัดเก็บข้อมูลเชิงพื้นที่

ฉันเพิ่งคุ้นเคยกับแนวคิดของgeography( the_geog) ประเภทข้อมูลที่ฉันเข้าใจมันเก็บไว้SRIDพร้อมกับเรขาคณิต

อะไรคือความแตกต่างระหว่างgeographyและgeometryและมีข้อดีของการใช้หนึ่งในฐานข้อมูลขนาดใหญ่หรือไม่

คุณสมบัติทางภูมิศาสตร์จะถูกเก็บไว้ใน WGS84 เสมอก่อน PostGIS 2.2; ตั้งแต่นั้นระบบการอ้างอิงเชิงพื้นที่ของ lon / lat ใด ๆ ก็สามารถใช้งานได้ การวัดตามคุณสมบัติทางภูมิศาสตร์จะมีหน่วยเป็นเมตรแทนที่จะเป็นหน่วย CRS และ PostGIS จะใช้การคำนวณทางภูมิศาสตร์แทนรูปทรงเรขาคณิตระนาบ

ไม่มีฟังก์ชั่นทั้งหมดที่รองรับรูปทรงเรขาคณิต แต่คุณสามารถแยกระหว่างรูปทรงเรขาคณิตและภูมิศาสตร์ สำหรับรายการฟังก์ชั่นปัจจุบันดูที่: https://postgis.net/docs/PostGIS_Special_Functions_Index.html#PostGIS_GeographyFunctions

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

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

ฉันพบว่ามีประโยชน์ดังต่อไปนี้: http://postgis.net/workshops/postgis-intro/geography.html

หัวข้อดังกล่าวยังรวมอยู่ใน "PostGIS in Action" (ISBN: 9781935182269)

ฉันใช้ "กฎง่ายๆ" ที่ใช้งานง่ายของฉัน ... มันมีประโยชน์สำหรับการตัดสินใจที่รวดเร็ว

• เกี่ยวกับฐานข้อมูล : ถ้าคุณสมบัติและ / หรือการวิเคราะห์เชิงพื้นที่ของคอนติเนนขนาดและความต้องการความแม่นยำ (โปรแกรมร้ายแรง) ใช้ภูมิศาสตร์ อื่นใช้เรขาคณิต: เมื่อฐานข้อมูลทั้งหมดอยู่ในภูมิภาคเดียวกัน (ระดับเมือง ) หรือคุณไม่ต้องการความแม่นยำ ฯลฯ คุณต้องมีรูปทรงเรขาคณิตเท่านั้น
  ดูกฎที่คล้ายกันที่แนะนำการบรรยายของ @underdark

• เกี่ยวกับความต้องการของคุณในแง่ของประสิทธิภาพการทำงาน / ความแม่นยำ สมดุล: เรขาคณิตเร็วขึ้น หากคุณต้องการประสิทธิภาพและคิดว่าใช้ภูมิศาสตร์ให้ทำเกณฑ์มาตรฐานของคุณก่อน

แนวคิดหลัก

ในหน้านี้เราเห็นบางคำที่สำคัญและมุ่งเน้นไปที่แนวคิดนี้มีความแม่นยำ , ประสิทธิภาพการทำงานและสิ่งที่ต้องการความยืดหยุ่น / สินค้าโภคภัณฑ์ในการใช้

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

• ทรงกลม (ภูมิศาสตร์) ดีกว่าแม่นยำยิ่งขึ้น ดูตัวอย่าง Los Angeles / ปารีส
• วิวัฒนาการของภูมิศาสตร์: @DavidF พูดว่า "มีการเพิ่มประเภททางภูมิศาสตร์เมื่อเร็ว ๆ นี้ดังนั้นจึงมีการรองรับ / ใช้งานฟังก์ชั่นน้อยลง"

บางทีในปี 2020 ฐานข้อมูล GIS ทั้งหมดจะถูกตั้งค่าเป็น SRID / EPSG มาตรฐานเดียวกัน (เทียบเท่ากับรหัสปัจจุบัน 4326 สำหรับ WGS84) ภูมิศาสตร์วันนี้ไม่ใช่ตัวเลือกเริ่มต้นเนื่องจากข้อ จำกัด ด้านประสิทธิภาพและการใช้งาน

อภิปรายผล

ในความคิดของฉันมันเป็นคำถามของ "การปฏิบัติที่ดีที่สุด" ไม่ใช่ปัญหาเชิงเทคนิค / เชิงทฤษฎี

ความแม่นยำ

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

ประสิทธิภาพ

ตัวอย่างของการวัดประสิทธิภาพในเขตเมือง ~ 100km2 (เส้นผ่าศูนย์กลาง ~ 11km) ซึ่งเก็บไว้เป็นรูปทรงเรขาคณิตในระบบพิกัดภาพถ่าย UTM หมายเหตุ: เริ่มต้นด้วยการแปลงรูปทรงเรขาคณิต / ภูมิศาสตร์ที่ใช้บ่อย - บ่อยครั้งเนื่องจากไม่มีฟังก์ชั่นบางฟังก์ชั่นและอื่น ๆ เช่น ST_Buffer และ ST_Intersection ทำการแปลงภายใน

Bench # 1: ตารางที่มี 87,000 polygons แสดงถึงล็อตในเมืองแต่ละอันมี poly ด้วย (avg) ~ 13 คะแนน

 BEGIN; EXPLAIN ANALYSE CREATE TABLE temp_geom AS 
        SELECT gid, the_geom FROM urbanlots; ROLLBACK;
 -- time 2080 ms   ~ 2.0 s
 BEGIN; EXPLAIN ANALYSE CREATE TABLE temp_geog AS 
        SELECT gid, Geography(ST_Transform(the_geom,4326)) AS geog 
        FROM urbanlots; ROLLBACK;
 -- time 12374 ms ~ 12.4 s  ~ 6 * geometry.

ดังนั้น geography_time = 6 * geometry_time

ม้านั่ง # 2: ตารางที่มี ~ 3500 รูปหลายเหลี่ยมซึ่งเป็นตัวแทนของเขตเมืองแต่ละตารางมีโพลีด้วย (เฉลี่ย) ~ 50 คะแนน: 0.6 วินาทีเทียบกับ 2.7 วินาที, ภูมิศาสตร์ = เวลา = 4.5 * geometry_time

Bench # 3: ~ 10,000 บรรทัดแสดงถนนในเมืองแต่ละเส้นมี ~ 5 points ~ 0.87s เทียบกับ ~ 0.36s, ภูมิศาสตร์ _time = 2.4 * geometry_time

กลับไปที่ Bench # 2 สร้างตารางและทำแบบสอบถาม

 EXPLAIN ANALYSE SELECT ST_Area(g.the_geom)+ST_Distance(g.the_geom,t.the_geom) 
         FROM temp_geom g, (SELECT the_geom FROM temp_geom WHERE gid=1) as t;
 -- time 182 ms   ~ 0.2 s
 EXPLAIN ANALYSE SELECT ST_Area(g.geog)+ST_Distance(g.geog,t.geog) 
         FROM temp_geog g, (SELECT geog FROM temp_geog WHERE gid=1) as t;
 -- time 58657 ms  ~ 59 s  ~  300*geometry
 -- curioselly for only distances, geography=4*geometry

สรุป: สำหรับงานเล็ก ๆ น้อย ๆ และผู้ที่เข้าใจยากดีเวลาที่มาบรรจบกันกับ "เวลาที่ยอมรับได้เหมือนกัน" แต่สำหรับงานใหญ่ ๆ มีการจัดอันดับประสิทธิภาพที่ต้องพิจารณา

ความยืดหยุ่น / สินค้าโภคภัณฑ์

ในการวัดประสิทธิภาพที่ฉันทำงานเป็นรายวันให้ตรวจสอบจำนวนคะแนน (โดยST_NPoints) ... มันเป็นตัวอย่างของการดำเนินการที่ไม่มีอยู่ในภูมิศาสตร์ "geography / geometry cast" เป็นงานที่น่ารำคาญสำหรับโปรแกรมเมอร์โปรแกรมเมอร์ผู้เชี่ยวชาญ ฯลฯ

เมื่อนำไลบรารีของฟังก์ชัน SQL และ PL / pgSQL กลับมาใช้ใหม่ภูมิศาสตร์จำเป็นต้องมีการดัดแปลง และหากคุณต้องการเพิ่มประสิทธิภาพรหัสหรือหลีกเลี่ยงปัญหาความแม่นยำด้วยการแปลงตัวกลางจำนวนมากการขาดฟังก์ชั่นการ build-in ที่สมบูรณ์พร้อมด้วยสภาพทางภูมิศาสตร์เป็นปัญหาอีกอย่างหนึ่ง โปรแกรมสำหรับภูมิศาสตร์ไม่ใช่เรื่องง่าย

กระบวนการแลกเปลี่ยนข้อมูลเท่านั้นเป็นต้น

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

ผมเชื่อว่าการรวมศูนย์ข้อมูลเป็นงานอื่นที่ทางภูมิศาสตร์จะดีกว่า: ในบริบทที่หลากหลายของรูปแบบการป้อนข้อมูลและระบบการอ้างอิงเป็นปกติการใช้มาตรฐานเช่นที่บังคับใช้โดยสภาพทางภูมิศาสตร์ที่เป็นประโยชน์ ... การประชุมมากกว่าการกำหนดค่าเป็น หลักการที่ดีเมื่อการรวมศูนย์และการแลกเปลี่ยนข้อมูลเป็นจุดสำคัญทางธุรกิจ (ดู Google Maps!)

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

เอกสารค่อนข้างดี: http://postgis.net/docs/manual-1.5/ch04.html#PostGIS_Geography

ประเภททางภูมิศาสตร์ได้รับการเพิ่มมากขึ้นเมื่อเร็ว ๆ นี้ดังนั้นจึงมีการรองรับ / ใช้งานฟังก์ชั่นน้อยลง

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

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