การออกแบบที่ดีที่สุดสำหรับต้นแบบ Open Source Python / PostGIS


9

ฉันกำลังเขียนเว็บแอปพลิเคชั่นที่เน้นข้อมูลที่ส่งผ่าน apache คำถามของฉันเกี่ยวกับวิธีจัดการการประมวลผลที่ดีที่สุดเนื่องจากมีหลายตัวเลือก

ฉันมี OpenLayers / JQuery / Javascript, PostGIS / Postgresql (พร้อม pgsql), python / psycopg2, php

ฐานข้อมูลมีแถวประมาณ 3 ล้านแถวและต้นแบบปัจจุบันทำงานดังนี้:

  • ผู้ใช้คลิกที่จุดบนหน้าต่าง OpenLayers

  • พิกัดถูกส่งเป็นการร้องขอ AJAX ไปยังฟังก์ชัน python บนเซิร์ฟเวอร์

  • ขณะนี้ใบสมัครของฉันไม่มีสัญชาติ

  • psycopg2 ของ Python ใช้เพื่อเรียกโพรซีเดอร์ที่เก็บไว้ pgsql และชุดค่า WKT ที่ยอดเยี่ยม (และฟิลด์ข้อมูล) จะถูกส่งกลับไปยังโมดูลหลาม

  • ฟิลด์ข้อมูลใช้เพื่อจัดหมวดหมู่เรคคอร์ด WKT ในไพ ธ อนดังนี้: ค่า WKT ทั้งหมดถูกจัดหมวดหมู่เป็นหนึ่งใน 5 กลุ่ม ประมาณ 1% ของค่า WKT จะถูกแก้ไขจริง

  • ห้าชุด / กลุ่มของ WKT ถูกบัฟเฟอร์เพื่อสร้างรูปหลายเหลี่ยมที่แตกต่างกันห้าแบบ ฉันเรียกขั้นตอนที่เก็บไว้ในฐานข้อมูลเพื่อทำสิ่งนี้ สิ่งนี้จะใช้เพียง ST_BUFFER (ฉันได้พิจารณาการใช้ Shapely แต่ไม่แน่ใจว่าจะมีข้อได้เปรียบด้านประสิทธิภาพเนื่องจากมีการใช้ไลบรารี GEOS ในกรณีใดกรณีหนึ่ง ... )

  • ในที่สุดค่าข้อความ 5 WKT จะถูกรวมอยู่ในสตริง JSON และส่งกลับไปยัง OpenLayers เพื่อแสดงเป็นห้าเลเยอร์

ฉันพบว่าคอขวดคือการค้นหาเชิงพื้นที่เริ่มต้นและขั้นตอนการบัฟเฟอร์สุดท้าย

ฉันเดาคำถามคือ:

มีวิธีที่ดีกว่าในการจัดเรียงสิ่งต่าง ๆ ? ตัวอย่างเช่นการประมวลผลข้อมูลทั้งหมดควรทำใน PostgreSQL (เช่นมีเคอร์เซอร์) และนี่จะเป็นสิ่งที่ดีในแง่ของการบำรุงรักษาและประสิทธิภาพหรือไม่? จะเป็นการดีกว่าถ้าใช้ไทล์เซิร์ฟเวอร์เพื่อหลีกเลี่ยงการส่งผ่านสาย WKT ที่ยาวไปยังเว็บไคลเอ็นต์? คุณจะจัดการกับมันอย่างไร?


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

Matthew - ฉันพยายามสร้างรูปหลายเหลี่ยมแบบเวลาขับรถ ฉันรู้บางอย่างเกี่ยวกับรูปหลายเหลี่ยมเว้า แต่ต้องการลองด้วยวิธีนี้เป็นหลักเพื่อความแม่นยำที่ดีกว่า รูปหลายเหลี่ยมเป็นบัฟเฟอร์ 200 เมตรของ MultiLinestrings (นั่นคือ: ถนน) ขณะนี้ฉันกำลังเล่นกับความคิดในการบัฟเฟอร์ล่วงหน้าทุกถนนในฐานข้อมูล แต่ฉันยังคงต้องรวมมันเข้าด้วยกัน \ n #
John Steedman

โดยทั่วไปฉันกำลังมองหาสถาปัตยกรรมที่มีความสมดุลของการประมวลผลทางภูมิศาสตร์อย่างมากกับส่วนติดต่อผู้ใช้บนเว็บที่ตอบสนอง: ไม่เร็วเท่ากับ Google แน่นอน แต่เป็นที่รู้จักในแง่ของความคาดหวังของผู้ใช้ในปัจจุบัน! นี่สำหรับผู้ใช้ที่มีกำลังน้อย
John Steedman

คำตอบ:


3

บัฟเฟอร์คอขวด

เมื่อใช้ ST_Buffer คุณสามารถลดความซับซ้อนของรูปร่างผลลัพธ์โดยเพิ่มตัวเลือก num_seg_quarter_circle ที่ต่ำกว่า สิ่งนี้ควรลดจำนวนการประมวลผลเมื่อบัฟเฟอร์และในการดำเนินการที่ตามมา

จากเอกสาร PostGIS:

ป้อนคำอธิบายรูปภาพที่นี่

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


2

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

ฉันขอแนะนำว่านอกเหนือจาก Python คุณดูที่ MapServer และ Geoserver เพื่อทำการคำนวณและสร้างผลลัพธ์ ทั้งคู่สามารถสร้างแผ่นภาพหรือเอาท์พุท GeoJSON ทั้งสองแอปพลิเคชันสามารถใช้ PostGIS เป็นแบ็คเอนด์


ขอบคุณเดวิด ฟังดูเหมือนเป็นนโยบายที่ดีซึ่งฉันได้ล่องลอยไปหาตัวเอง ฉันจะดู GeoServer เพื่อดูภาพย่อย ฉันเคยใช้ python / mapnik มาก่อนในเรื่องนี้
John Steedman

สิ่งอื่น ๆ ที่ฉันเพิ่งค้นพบคือการกลับแถวผ่านขั้นตอนการจัดเก็บช้ามาก (มากมาก)
John Steedman
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.