คุณจัดการกับคุณสมบัติ 3 มิติบางส่วนใน PostGIS อย่างไร

10

เรามีคุณสมบัติจากข้อมูลการสำรวจที่มีข้อมูล 3 มิติบางส่วน

ตัวอย่างที่พบบ่อยที่สุดคือ LineString 2D ซึ่งเป็นถนนที่มีข้อมูลระดับความสูงในบางจุดที่มีการสำรวจ ตัวอย่างอื่น ๆ ได้แก่ รูปร่างหลังคา - MultiLineString ที่บางประเด็นสำคัญมีการยกระดับที่กำหนดจากแผนอาคาร แต่ไม่ใช่ทั้งหมด

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

postgis data 3d model

— relet
แหล่งที่มา

LineString 2D แสดงถนนที่มีระดับความสูง - เพื่อให้เป็นแบบ 3 มิติ - ใช้ ST_Force_3D สำหรับข้อมูลของคุณ - postgis.refractions.net/documentation/manual-1.5SVN/…

— Mapperz

พิกัด 0 z ไม่ถูกต้องและไม่ได้แสดงค่าเดียวกันกับแหล่งข้อมูล ST_Force_3D จะไม่ทำงานสำหรับเรา แนวคิดนี้คือเพื่อให้สามารถทำแผนที่สองทิศทางที่ถูกต้องระหว่างแหล่งข้อมูลกับฐานข้อมูลของเรา

— relet

2

คุณสามารถจัดเก็บที่ไม่ได้วัดค่า Z 'nan'::float8เป็น ตัวอย่างเช่น:

SELECT ST_AsText(g), ST_X(g), ST_Y(g), ST_Z(g), ST_Z(g) <> 'nan'::float8 AS has_z
FROM (
  SELECT ST_MakePoint(1, 2, 'nan'::float8) AS g
  UNION SELECT ST_MakePoint(4, 5, 6) AS g
) AS f;

       st_astext       | st_x | st_y | st_z | has_z
-----------------------+------+------+------+-------
 POINT Z (1 2 1.#QNAN) |    1 |    2 |  NaN | f
 POINT Z (4 5 6)       |    4 |    5 |    6 | t
(2 rows)

อย่างไรก็ตามสิ่งนี้อาจทำให้คุณมีปัญหาเนื่องจากค่า NaN ไม่ได้ทดสอบหรือจัดการโดยนักพัฒนาซอฟต์แวร์เสมอไป เช่น PostGIS ไม่สามารถแยกรุ่น WKT ด้านบน

SELECT 'POINT Z (1 2 1.#QNAN)'::geometry;

ERROR:  parse error - invalid geometry
LINE 1: SELECT 'POINT Z (1 2 1.#QNAN)'::geometry;
               ^
HINT:  "POINT Z (1 2 1.#Q" <-- parse error at position 17 within geometry

— ไมค์ที
แหล่งที่มา

1

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

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

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

สิ่งนี้ถูกต้องจากโมเดลเชิงสัมพันธ์ด้วยเช่นกัน:

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

สำหรับกรณี multilinestring สิ่งต่าง ๆ อาจจะยากกว่านี้เล็กน้อยเนื่องจากตอนนี้ต้องมีตารางเพิ่มเติมที่มีคีย์หลักผสมอยู่แล้ว:

rowid (gid, ตัวระบุที่ไม่ซ้ำกัน) ของเรขาคณิตแหล่งที่มา
ตำแหน่ง geometryN ภายใน MultiGeometry ที่ระบุซึ่งต้องตรวจสอบว่าอยู่ภายในช่วงเวลา [1-N]
คีย์ foreing ไปยัง rowid ของตารางที่เกี่ยวข้อง (gid)
ฟังก์ชั่นทริกเกอร์ / ตรวจสอบเพื่อให้แน่ใจว่าช่วงเวลาที่ถูกต้อง

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

การทำให้เข้าใจง่ายจะเป็นการใช้คอลัมน์เพิ่มเติม แต่ไม่ใช่เรขาคณิตชนิด แต่มีค่า Z ชนิดเดียวกันที่ประกาศเป็นอาร์เรย์

— cavila
แหล่งที่มา