¿Cómo se tratan las características 3D parciales en PostGIS?

Tenemos características de datos de encuestas que contienen información parcial en 3D.

El ejemplo más común sería un LineString 2D que representa una carretera, que contiene información de elevación en ciertos puntos donde se encuestó. Otros ejemplos incluyen formas de techo: un MultiLineString donde algunos puntos clave tienen una elevación asignada desde el plano del edificio, pero no todos.

Usando PostGIS, ¿qué modelo de datos recomendaría para almacenar este tipo de información, para mantenerla lo más accesible posible, sin perder o generar información interpolada?

Puede almacenar los valores Z no medidos como 'nan'::float8. Por ejemplo:

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)

Sin embargo, esto podría meterlo en problemas ya que los valores de NaN no siempre son probados o manejados por los desarrolladores de software. Por ejemplo, PostGIS no puede analizar la versión WKT de lo anterior

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

Cree una columna de geometría secundaria con tres dimensiones para contener los vértices de la cadena lineal que tiene los valores de tres ordenadas (triples). Para que este esquema funcione, se asumen los siguientes supuestos:

• la cadena lineal es válida, no contiene puntos duplicados
• las geometrías son cadenas lineales
• debe haber al menos dos vértices con coordenadas 3d en una geometría dada para que sea elegible para almacenarse en una columna de geometría secundaria
• un disparador llenará la columna de geometría secundaria para mantenerla ÁCIDA.

La geometría válida debería ser suficiente para no permitir puntos duplicados en cadenas lineales y sin auto intersección. Por lo tanto, cada coordenada se comportará como una clave primaria para identificar el vértice en la geometría de origen.

Esto también es correcto a partir del modelo relacional:

• no habrá reducción, el vértice sin información no apareció en la columna de geometría secundaria
• Los cambios en los datos de origen se propagarán a los datos derivados por el activador.
• solo la información que se considera verdadera se almacenará en la base de datos, no se crearán datos artificiales.

Para el caso de multilínea, las cosas pueden ser un poco más difíciles ya que ahora debe tener una tabla adicional con una clave primaria compuesta:

• el rowid (gid, un identificador único) de la geometría fuente
• la posición geometryN dentro de la MultiGeometry dada que debe verificarse dentro del intervalo [1-N]
• una clave externa para la tabla relacionada rowid (gid)
• una función de activación / verificación para garantizar que el intervalo sea válido

La clave principal anterior evitará la inserción de índices de geometría duplicados para una geometría dada. El disparador / verificación evitará índices no válidos. También las filas aquí deben ser de datos de origen dada la clave externa. Se aplican todas las reglas anteriores.

Una simplificación sería el uso de una columna adicional, pero no de geometría amable, sino del mismo tipo de valor Z declarado como matriz.