¿Existe un valor Z ficticio estandarizado o "más utilizado"?

10

Al crear e importar datos 2D y 3D, muchas veces me he encontrado con la situación en la que no tengo valor Z para un conjunto de coordenadas, que el valor de una coordenada Z parece estar fuera de rango (como -99, -9999, -inf o similar ) o que necesito crear una coordenada Z falsa .

Sé que la respuesta a mi pregunta es:

"Simplemente use un valor que definitivamente esté fuera de rango en su caso".

Pero dejando de lado esa respuesta. Me pregunto si la comunidad SIG tiene un valor estandarizado o más utilizado para una coordenada Z simulada .

Chau
fuente

Respuestas:

5

Las respuestas actuales dan buenos consejos. Una regla general (de la comunidad científica informática) que funciona bien en los casos en que no puede almacenar nulos verdaderos o NaNs es usar el valor más pequeño (más negativo) que el campo mantendrá (válido).

Ejemplos:

  • Un campo decimal de 7.2 puede contener un valor tan pequeño como -9999.99.

  • Un ráster entero puede contener números tan pequeños como -32768, pero a menudo (debido a una aversión al binario y una afinidad por la base 10) se usa el valor -9999.

  • Un flotador puede contener números del orden de -10 ^ (38). Si no puede poner un NaN en el campo, encuentre el flotador más pequeño que se ajuste (lo cual es un dolor) o simplemente use algo como -10 ^ (38) en sí mismo. Para dobles, -10 ^ (303) funciona bien, pero también lo hace -10 ^ (38): es suficientemente grande y negativo para servir como un marcador claro de un valor nulo.

Esta regla es simple de recordar, coherente, fácil de aplicar, fácil de documentar de forma repetitiva (para sus metadatos), y rara vez conduce a errores involuntarios (porque el número más negativo suele ser tan diferente de los datos que su mal uso como el valor real, en lugar de ser un valor nulo, corrompe los resúmenes estadísticos y otros cálculos lo suficiente como para generar una señal de que hay un problema).

whuber
fuente
5

Si sus datos están en una base de datos, lo ideal sería utilizar un valor NULL :

una representación de "información faltante e información inaplicable"

Sin embargo, esto podría causar problemas con las aplicaciones y el código del cliente, y no creo que NULL sea compatible con DBF. Cuál debería ser ese valor, supongo, es diferente para diferentes convenciones organizacionales. Cualquiera que sea el valor ficticio que elija, asegúrese de que esté registrado en los metadatos del conjunto de datos.

Si ninguno de los puntos de un conjunto de datos tiene un valor Z, entonces no veo por qué no se pudo utilizar 0, aunque en ese caso tal vez sea mejor eliminar completamente la conciencia Z del conjunto de datos para evitar confusiones.

geographika
fuente
2
+1 La mayoría de los productos ESRI, así como la mayoría de los demás software, leerán nulos en los campos numéricos de dBase como ceros. Eso es mortal, por lo que generalmente es importante usar una codificación nula explícita en archivos .dbf (que incluye archivos de forma).
whuber
4

La mayoría de los rásteres que he encontrado usan -9999.0 para datos de punto flotante como una convención, y GDAL usará -dbl_inf cuando esté escribiendo código para una imagen que no tiene un valor nodata / ficticio. RGB de 8 bits usualmente usará 0 0 0 o 255 255 255, o tendrá un canal alfa o máscara.

Las coberturas GML 3 (para las cuales no hay una gran cantidad de soporte en este momento, pero eso cambiará cuando se ratifique la especificación WCS 2) tiene varios valores ficticios que se representan como texto como "falta" y "retenido".

Según mi experiencia, cualquier defecto tiende a ser específico del dominio o del proveedor. Si usted es el productor de datos en lugar del consumidor, elija un número y manténgalo y asegúrese de que sus consumidores estén al tanto de ello.

MerseyViking
fuente
2

Me gustaría utilizar NaN debido a operaciones matemáticas producirán otros NaNs o excepciones de tiro. De esa manera, puede detectar muy pronto que se está equivocando porque está utilizando un valor falso

Ragi Yaser Burhum
fuente
2
NaN estaría bien para los cálculos (con valores de coma flotante), pero no puede almacenar NaN en muchas bases de datos o formatos de datos SIG
geographika
2
+1 @geographika es correcto. Sin embargo, el punto sobre el uso de un valor que arruinará los cálculos es excelente.
whuber
para enteros puede tener NaNs: numeric_limits <int> :: quiet_NaN ()
Ragi Yaser Burhum
Además, mi recomendación fue que el uso de NaN se relacionara con el valor Z dentro de la geometría. Así que, independientemente de si el valor está en una base de datos o no, en mi humilde opinión que se debe serializar con la geometría - por lo que sólo debe trabajar ...
Ragi Yaser Burhum