Come trattate le funzioni 3d parziali in PostGIS?

Abbiamo caratteristiche dai dati del sondaggio che contengono informazioni 3d parziali.

L'esempio più comune sarebbe un LineString 2D che rappresenta una strada, che contiene informazioni sull'altitudine in determinati punti in cui è stata rilevata. Altri esempi includono le forme del tetto: una MultiLineString in cui alcuni punti chiave hanno un'elevazione assegnata dal piano dell'edificio, ma non tutti.

Utilizzando PostGIS, quale modello di dati consiglieresti di archiviare questo tipo di informazioni, per renderlo il più accessibile possibile, senza perdere o generare informazioni interpolate?

È possibile memorizzare i valori Z non misurati come 'nan'::float8. Per esempio:

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)

Tuttavia, ciò potrebbe metterti nei guai poiché i valori NaN non sono sempre testati o gestiti dagli sviluppatori di software. Ad esempio, PostGIS non può analizzare la versione WKT di cui sopra

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

Crea una colonna di geometria secondaria con tre dimensioni per contenere i vertici della stringa di linea che ha i valori di tre ordinate (triple). Perché questo schema funzioni i seguenti presupposti:

• la stringa di linea è valida, non contiene punti duplicati
• le geometrie sono linestring
• ci devono essere almeno due vertici con coordinate 3d in una data geometria perché sia ​​idoneo a essere memorizzato in una colonna di geometria secondaria
• un trigger riempirà la colonna della geometria secondaria per mantenerlo ACIDO.

La geometria valida dovrebbe essere sufficiente per non consentire punti duplicati nelle stringhe di linea e nessun autointersezione. Quindi ogni coordinata si comporterà come una chiave di base per identificare il vertice nella geometria di origine.

Ciò è corretto anche dal modello relazionale:

• non ci sarà ridondanza, il vertice senza informazioni non appariva nella colonna della geometria secondaria
• le modifiche ai dati di origine verranno propagate ai dati derivati ​​dal trigger.
• solo le informazioni considerate la verità verranno archiviate nel database, non verranno creati dati artificiali.

Nel caso della multistringa, le cose possono essere un po 'più difficili, dato che ora deve esserci una tabella aggiuntiva con una chiave primaria composita:

• il rowid (gid, un identificatore univoco) della geometria di origine
• la posizione della geometria N all'interno della data MultiGeometry che deve essere verificata all'interno dell'intervallo [1-N]
• una chiave di avanzamento per la tabella relativa rowid (gid)
• una funzione trigger / check per garantire che l'intervallo sia valido

La chiave primaria sopra impedirà l'inserimento di indici geometrici duplicati per una data geometria. Il trigger / controllo impedirà gli indici non validi. Anche le righe qui devono provenire dai dati di origine dati la chiave esterna. Si applicano tutte le regole precedenti.

Una semplificazione sarebbe l'uso di una colonna aggiuntiva ma non di una geometria gentile ma dello stesso tipo di valore Z dichiarato come array.