Bagaimana Anda memperlakukan fitur 3d parsial di PostGIS?

Kami memiliki fitur dari data survei yang berisi sebagian informasi 3d.

Contoh paling umum adalah 2D LineString yang mewakili jalan, yang berisi informasi ketinggian di titik-titik tertentu di mana ia disurvei. Contoh lain termasuk bentuk atap - A MultiLineString di mana beberapa titik utama memiliki elevasi yang ditetapkan dari rencana bangunan, tetapi tidak semua.

Menggunakan PostGIS, model data mana yang akan Anda rekomendasikan untuk menyimpan informasi semacam ini, agar tetap dapat diakses semaksimal mungkin, tanpa kehilangan atau menghasilkan informasi yang diinterpolasi?

Anda bisa menyimpan nilai Z yang tidak terukur sebagai 'nan'::float8. Sebagai contoh:

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)

Namun, ini bisa membuat Anda bermasalah karena nilai-nilai NaN tidak selalu diuji atau ditangani oleh pengembang perangkat lunak. Misalnya, PostGIS tidak dapat menguraikan versi WKT di atas

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

Buat kolom geometri sekunder dengan tiga dimensi untuk menahan titik-titik linestring yang memiliki nilai tiga-ordinat (rangkap tiga). Agar skema ini berfungsi, asumsi-asumsi berikut diasumsikan:

• linestring valid, tidak mengandung duplikasi poin
• geometri adalah linestrings
• harus ada setidaknya dua simpul dengan koordinat 3d ke dalam geometri yang diberikan agar layak disimpan ke dalam kolom geometri sekunder
• pemicu akan mengisi kolom geometri sekunder agar tetap ACID.

Geometri yang valid harus cukup untuk tidak memungkinkan titik duplikasi di linestrings dan tidak ada persimpangan sendiri. Jadi setiap koordinat akan berperilaku seperti kunci utama untuk mengidentifikasi titik dalam geometri sumber.

Ini juga benar dari model relasional:

• tidak akan ada redudansi, simpul tanpa info tidak muncul ke dalam kolom geometri sekunder
• perubahan pada sumber data akan disebarkan ke data yang diturunkan oleh pemicu.
• hanya informasi yang dianggap kebenaran yang akan disimpan dalam database, tidak ada data buatan yang dibuat.

Untuk kasus multilinestring hal-hal bisa menjadi sedikit lebih sulit karena sekarang harus memiliki tabel tambahan dengan kunci primer komposit:

• rowid (gid, pengidentifikasi unik) dari geometri sumber
• posisi geometri di dalam MultiGeometry yang diberikan yang harus memeriksa apakah ada di dalam interval [1-N]
• kunci foreing ke rowid tabel terkait (gid)
• fungsi trigger / check untuk memastikan intervalnya valid

Kunci utama di atas akan mencegah sisipan indeks geometri duplikat untuk geometri yang diberikan. Pemicu / pemeriksaan akan mencegah indeks tidak valid. Baris di sini juga harus dari sumber data yang diberikan kunci asing. Semua aturan sebelumnya berlaku.

Penyederhanaan akan menjadi penggunaan pada kolom tambahan tetapi tidak dari jenis geometri tetapi dari jenis nilai Z yang sama dinyatakan sebagai array.