Как вы относитесь к частичным 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

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

Линейная строка действительна, она не содержит дублированных точек
геометрия линейных нитей
в заданной геометрии должно быть как минимум две вершины с трехмерными координатами, чтобы их было удобно хранить в столбце вторичной геометрии
триггер заполнит столбец вторичной геометрии, чтобы сохранить его ACID.

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

Это верно и для реляционной модели:

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

Для случая со множеством строк все может быть немного сложнее, так как теперь должна быть дополнительная таблица с составным первичным ключом:

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

Приведенный выше первичный ключ предотвратит вставку дублированных индексов геометрии для данной геометрии. Триггер / проверка предотвратит недопустимые индексы. Также строки здесь должны быть из исходных данных с учетом внешнего ключа. Все предыдущие правила применяются.

Упрощением будет использование дополнительного столбца, но не типа геометрии, а того же типа значения Z, объявленного как массив.

— cavila
источник