Comment traitez-vous les fonctionnalités 3D partielles dans PostGIS?

Nous avons des fonctionnalités de données d'enquête qui contiennent des informations 3D partielles.

L'exemple le plus courant serait un LineString 2D représentant une route, qui contient des informations d'altitude à certains points où il a été arpenté. D'autres exemples incluent les formes de toit - Une chaîne MultiLineString où certains points clés ont une élévation attribuée par rapport au plan de construction, mais pas tous.

À l'aide de PostGIS, quel modèle de données recommanderiez-vous pour stocker ce type d'informations, afin de les rendre aussi accessibles que possible, sans perdre ou générer des informations interpolées?

Vous pouvez stocker les valeurs Z non mesurées sous la forme 'nan'::float8. Par exemple:

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)

Cependant, cela pourrait vous poser des problèmes car les valeurs NaN ne sont pas toujours testées ou gérées par les développeurs de logiciels. Par exemple, PostGIS ne peut pas analyser la version WKT de ce qui précède

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

Créez une colonne de géométrie secondaire à trois dimensions pour contenir les sommets de la chaîne de lignes contenant les valeurs à trois ordonnées (triple). Pour que ce schéma fonctionne, les hypothèses suivantes sont supposées:

• la chaîne de caractères est valide, elle ne contient pas de points dupliqués
• les géométries sont des chaînes de lignes
• il doit y avoir au moins deux sommets avec des coordonnées 3D dans une géométrie donnée pour qu'il soit élégant d'être stocké dans une colonne de géométrie secondaire
• un déclencheur remplira la colonne de géométrie secondaire pour la garder ACIDE.

La géométrie valide devrait être suffisante pour ne pas autoriser les points dupliqués dans les chaînes de lignes et aucune auto-intersection. Ainsi, chaque coordonnée se comportera comme une clé de primery pour identifier le sommet dans la géométrie source.

Cela est également vrai du modèle relationnel:

• il n'y aura pas de redudance, le sommet sans info n'apparaît pas dans la colonne de géométrie secondaire
• les modifications des données source seront propagées aux données dérivées par le déclencheur.
• seules les informations considérées comme véridiques seront stockées dans la base de données, aucune donnée artificielle créée.

Pour le cas multiligne, les choses peuvent être un peu plus difficiles, car il doit maintenant y avoir une table supplémentaire avec une clé primaire composite:

• le rowid (gid, un identifiant unique) de la géométrie source
• la position geometryN à l'intérieur de la MultiGeometry donnée qui doit être vérifiée à l'intérieur de l'intervalle [1-N]
• une clé étrangère pour le tableau associé rowid (gid)
• une fonction de déclenchement / vérification pour s'assurer que l'intervalle est valide

La clé primaire ci-dessus empêchera l'insertion d'index de géométrie dupliqués pour une géométrie donnée. Le déclencheur / contrôle empêchera les index invalides. Les lignes ici doivent également provenir des données source étant donné la clé étrangère. Toutes les règles précédentes s'appliquent.

Une simplification serait l'utilisation de sur colonne supplémentaire mais pas de géométrie aimable mais du même type de valeur Z déclarée comme tableau.