Existe um valor Z fictício padronizado ou "mais usado"?

Ao criar e importar dados 2D e 3D, muitas vezes encontrei a situação em que não tenho valor Z para um conjunto de coordenadas, que o valor de uma coordenada Z parece fora do intervalo (como -99, -9999, -inf ou similar ) ou que eu preciso criar uma coordenada Z fictícia .

Eu sei que a resposta para minha pergunta é:

"Basta usar um valor que esteja definitivamente fora de alcance no seu caso".

Mas essa resposta deixada de lado, pergunto-me se a comunidade GIS tem um valor padronizado ou usado com mais frequência para uma coordenada Z fictícia ?

Todas as respostas atuais dão bons conselhos. Uma regra geral (da comunidade científica da computação) que funciona bem nos casos em que você não pode armazenar nulos verdadeiros ou NaNs é usar o menor valor (mais negativo) que o campo reter (validamente).

Exemplos:

• Um campo decimal 7.2 pode conter um valor tão pequeno quanto -9999.99.

• Uma varredura inteira pode conter números tão pequenos quanto -32768, mas frequentemente (devido a uma aversão ao binário e uma afinidade pela base 10), o valor -9999 é usado.

• Um flutuador pode conter números da ordem de -10 ^ (38). Se você não pode colocar um NaN em campo, encontre o menor flutuador que caiba (o que é doloroso) ou use apenas algo como -10 ^ (38). Para duplos, -10 ^ (303) funciona bem, mas também -10 ^ (38): é suficientemente grande e negativo para servir como um marcador claro de um valor nulo.

Essa regra é simples de lembrar, consistente, fácil de aplicar, fácil de documentar de maneira padronizada (para seus metadados) e raramente leva a erros inadvertidos (porque o número mais negativo é geralmente tão diferente dos dados que seu uso incorreto como um o valor real, em vez de nulo, corrompe resumos estatísticos e outros cálculos suficientes para levantar uma sinalização de que há um problema).

Se seus dados estiverem em um banco de dados, o ideal seria usar um valor NULL :

uma representação de "informações ausentes e informações inaplicáveis"

No entanto, isso pode causar problemas com aplicativos e código do cliente, e eu não acredito que o NULL seja suportado nos DBFs. Acho que esse valor deve ser diferente para diferentes convenções organizacionais. Qualquer que seja o valor fictício escolhido, verifique se ele está registrado nos metadados do conjunto de dados.

Se nenhum dos pontos de um conjunto de dados tem um valor Z, não vejo por que 0 não pode ser usado, embora nesse caso talvez seja melhor remover completamente o reconhecimento de Z do conjunto de dados para evitar confusão.

A maioria dos rasters que encontrei usam -9999.0 para dados de ponto flutuante como convenção, e o GDAL usa -dbl_inf quando você estiver escrevendo código para uma imagem que não possui um valor nodata / fictício. O RGB de 8 bits geralmente usa 0 0 0 ou 255 255 255 ou possui um canal alfa ou de máscara.

As coberturas GML 3 (para as quais não há muito suporte no momento, mas que serão alteradas quando a especificação do WCS 2 for ratificada) têm vários valores fictícios que são representados como texto como "ausente" e "retido".

Na minha experiência, qualquer padrão tende a ser específico do domínio ou específico do fornecedor. Se você é o produtor de dados e não o consumidor, escolha um número e atenha-se a ele e verifique se seus consumidores estão cientes disso.

Eu usaria o NaN porque operações matemáticas produzirão outros NaNs ou lançarão exceções. Dessa forma, você pode detectar, na verdade, que está bagunçando porque está usando um valor falso