Existe-t-il une valeur Z fictive normalisée ou «la plus utilisée»?

En créant et en important des données 2D et 3D, j'ai souvent rencontré la situation où je n'ai pas de valeur Z pour un jeu de coordonnées, que la valeur d'une coordonnée Z semble hors de portée (comme -99, -9999, -inf ou similaire ) ou que je dois créer une coordonnée Z fictive .

Je sais que la réponse à ma question est:

"Utilisez simplement une valeur qui est certainement hors de portée dans votre cas."

Mais cette réponse mise de côté, je me demande si la communauté SIG a une valeur normalisée ou la plus fréquemment utilisée pour une coordonnée Z fictive ?

Les réponses actuelles donnent toutes de bons conseils. Une règle générale (de la communauté du calcul scientifique) qui fonctionne bien dans les cas où vous ne pouvez pas stocker de véritables valeurs nulles ou NaN est d' utiliser la plus petite valeur (la plus négative) que le champ contiendra (valablement).

Exemples:

• Un champ décimal 7.2 peut contenir une valeur aussi petite que -9999,99.

• Un raster entier peut contenir des nombres aussi petits que -32768, mais souvent (en raison d'une aversion pour le binaire et d'une affinité pour la base 10), la valeur -9999 est utilisée à la place.

• Un flotteur peut contenir des nombres de l'ordre de -10 ^ (38). Si vous ne pouvez pas mettre un NaN sur le terrain, trouvez le plus petit flotteur qui conviendra (ce qui est pénible) ou utilisez simplement quelque chose comme -10 ^ (38) lui-même. Pour les doubles, -10 ^ (303) fonctionne très bien, mais -10 ^ (38) aussi: il est suffisamment énorme et négatif pour servir de marqueur clair d'une valeur nulle.

Cette règle est simple à retenir, cohérente, facile à appliquer, facile à documenter de manière standard (pour vos métadonnées), et conduit rarement à des erreurs involontaires (car le nombre le plus négatif est généralement si différent des données que son utilisation abusive en tant que la valeur réelle, au lieu d'être nulle, corrompt suffisamment les résumés statistiques et autres calculs pour signaler qu'il y a un problème).

Si vos données sont dans une base de données, vous utiliseriez idéalement une valeur NULL :

une représentation des "informations manquantes et des informations inapplicables"

Cependant, cela pourrait provoquer des problèmes avec les applications clientes et le code, et je ne pense pas que NULL soit pris en charge dans les DBF. Ce que cette valeur devrait être, je suppose, est différent pour différentes conventions organisationnelles. Quelle que soit la valeur fictive que vous choisissez, assurez-vous qu'elle est enregistrée dans les métadonnées de l'ensemble de données.

Si aucun des points d'un ensemble de données n'a de valeur Z, je ne vois pas pourquoi 0 ne pourrait pas être utilisé, bien que dans ce cas, il est peut-être préférable de supprimer complètement la conscience Z de l'ensemble de données pour éviter toute confusion.

La plupart des rasters que j'ai rencontrés utilisent -9999.0 pour les données à virgule flottante comme convention, et GDAL utilisera -dbl_inf lorsque vous écrivez du code pour une image qui n'a pas de valeur nodata / fictive. RVB 8 bits utilisera généralement 0 0 0 ou 255 255 255, ou aura un canal alpha ou masque.

Les couvertures GML 3 (pour lesquelles il n'y a pas beaucoup de support pour le moment, mais qui changeront lorsque la spécification WCS 2 sera ratifiée) ont plusieurs valeurs fictives qui sont représentées sous forme de texte tel que "manquant" et "retenu".

Selon mon expérience, tout défaut a tendance à être spécifique au domaine ou au fournisseur. Si vous êtes le producteur de données plutôt que le consommateur, choisissez un nombre et respectez-le et assurez-vous que vos consommateurs en sont conscients.

J'utiliserais NaN car les opérations mathématiques produiront d'autres NaN ou lèveront des exceptions. De cette façon, vous pouvez détecter à peu près que vous vous trompez parce que vous utilisez une valeur fausse