Esiste un valore fittizio Z standardizzato o "più usato"?

Creando e importando dati 2D e 3D, ho riscontrato molte volte la situazione in cui non ho un valore Z per un set di coordinate, che il valore di una coordinata Z sembra fuori intervallo (come -99, -9999, -inf o simile ) o che devo creare una coordinata Z fittizia .

So che la risposta alla mia domanda è:

"Usa solo un valore che è decisamente fuori portata nel tuo caso."

Ma quella risposta a parte mi chiedo se la comunità GIS abbia un valore standardizzato o più frequentemente usato per una coordinata Z fittizia ?

Le risposte attuali danno tutti buoni consigli. Una regola generale (della comunità scientifica scientifica) che funziona bene nei casi in cui non è possibile memorizzare valori Null o NaN reali è utilizzare il valore più piccolo (più negativo) che il campo terrà (validamente).

Esempi:

• Un campo decimale 7.2 può contenere un valore piccolo come -9999,99.

• Un raster intero può contenere numeri piccoli come -32768, ma spesso (a causa di un'avversione al binario e un'affinità per la base 10) viene invece utilizzato il valore -9999.

• Un float può contenere numeri nell'ordine di -10 ^ (38). Se non riesci a mettere una NaN sul campo, trova il galleggiante più piccolo che si adatta (il che è un dolore) o usa semplicemente qualcosa come -10 ^ (38) stesso. Per i doppi, -10 ^ (303) funziona bene, ma anche -10 ^ (38): è sufficientemente grande e negativo da servire come marcatore chiaro di un valore nullo.

Questa regola è semplice da ricordare, coerente, facile da applicare, facile da documentare in modo standard (per i tuoi metadati) e raramente porta a errori involontari (perché il numero più negativo è di solito così diverso dai dati che il suo uso improprio come il valore effettivo, anziché un valore nullo, corrompe i riepiloghi statistici e altri calcoli abbastanza da sollevare una bandiera che si verifica un problema).

Se i tuoi dati sono in un database, idealmente dovresti usare un valore NULL :

una rappresentazione di "informazioni mancanti e informazioni inapplicabili"

Tuttavia, ciò potrebbe causare problemi con le applicazioni client e il codice e non credevo che NULL fosse supportato nei DBF. Quale sia il valore dovrebbe essere diverso per le diverse convenzioni organizzative. Qualunque sia il valore fittizio che scegli, assicurati che sia registrato nei metadati del set di dati.

Se nessuno dei punti per un set di dati ha un valore Z, non vedo perché 0 non possa essere utilizzato, anche se in tal caso forse è meglio rimuovere completamente la consapevolezza Z del set di dati per evitare confusione.

La maggior parte dei raster che ho incontrato usano -9999.0 per dati a virgola mobile come una convenzione e GDAL utilizzerà -dbl_inf quando si scrive codice per un'immagine che non ha un valore nodata / dummy. L'RGB a 8 bit userà normalmente 0 0 0 o 255 255 255 o avrà un canale alfa o maschera.

Le copertine di GML 3 (per le quali al momento non c'è molto supporto, ma che cambierà quando viene ratificata la specifica WCS 2) hanno diversi valori fittizi che sono rappresentati come testo come "mancante" e "trattenuto".

In base alla mia esperienza, qualsiasi impostazione predefinita tende a essere specifica del dominio o del fornitore. Se sei il produttore di dati piuttosto che il consumatore, scegli un numero e seguilo e assicurati che i tuoi consumatori ne siano consapevoli.

Vorrei usare NaN perché le operazioni matematiche produrranno altri NaNs o eccezioni tiro. In questo modo è possibile rilevare apparentemente che si sta incasinando perché si utilizza un valore falso