Як ви ставитеся до часткових 3d функцій у PostGIS?

10

У нас є функції з даних опитування, які містять часткову 3d інформацію.

Найпоширенішим прикладом може бути 2D LineString, що представляє дорогу, яка містить інформацію про висоту в певних точках, де її обстежували. Інші приклади включають форми даху - MultiLineString, де деякі ключові моменти мають відведений підйом від плану будівлі, але не всі.

Використовуючи PostGIS, яку модель даних ви б рекомендували зберігати подібну інформацію, щоб вона була максимально доступною, не втрачаючи і не створюючи інтерпольовану інформацію?

postgis data 3d model

— реле
джерело

2D LineString, що представляє дорогу, яка містить висоту - так, що це 3D - використовуйте 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

Створіть стовпчик вторинної геометрії з трьома вимірами, щоб утримувати вершини рядкових рядків, що мають триординатні (потрійні) значення. Щоб ця схема працювала, передбачаються наступні припущення:

рядок рядка дійсний, він не містить дублюваних точок
геометрії - це рядки
повинно бути принаймні дві вершини з 3d координатами в заданій геометрії, щоб воно було елегантним для зберігання у вторинному стовпчику геометрії
тригер заповнить стовпчик вторинної геометрії, щоб зберегти його ACID.

Дійсна геометрія повинна бути достатньою, щоб не дозволяти дублювати точки в рядках рядків і не мати самостійного перетину. Таким чином, кожна координата поводитиметься як ключ праймера для ідентифікації вершини в геометрії джерела.

Це правильно і в реляційній моделі:

не буде повторного зменшення, вершина без інформації не відображається у стовпчику геометрії
зміни вихідних даних будуть поширюватися на похідні дані тригером.
у базі даних зберігатиметься лише інформація, яка вважається правдою , не створюються штучні дані.

У випадку з багаторядковим рядком речі можуть бути дещо складнішими, оскільки тепер повинна бути додаткова таблиця з складеним первинним ключем:

рядовий (gid, унікальний ідентифікатор) геометрії джерела
положення геометріїN всередині даної MultiGeometry, яке повинно бути перевірено, що знаходиться всередині інтервалу [1-N]
ключ передбачення до пов'язаної таблиці rowid (gid)
функція спрацьовування / перевірки, щоб забезпечити дійсність інтервалу

Первинний ключ, зазначений вище, запобігає вставленню дублюваних індексів геометрії для заданої геометрії. Тригер / перевірка запобігає недійсним індексам. Також рядки тут повинні бути з вихідних даних, наданих іноземним ключем. Діють усі попередні правила.

Спрощенням було б використання додаткового стовпця, але не доброї геометрії, а того ж типу значення Z, оголошеного як масив.

— cavila
джерело