Is there a standardized or "most used" dummy Z value?

If your data is in a database then ideally you'd use a NULL value:

a representation of "missing information and inapplicable information"

However this could cause issues with client applications and code, and I don't believed NULL is supported in DBFs. What that value should be I guess is different for different organisational conventions. Whatever dummy value you do pick, make sure it is recorded in the dataset's metadata.

If none of the points for a dataset has a Z value then I don't see why 0 couldn't be used, although in that case maybe its best to remove the Z-awareness of the dataset completely to avoid confusion.


Current replies all give good advice. A general rule (from the scientific computing community) that works well in cases where you cannot store true nulls or NaNs is use the smallest (most negative) value the field will (validly) hold.

Examples:

  • A 7.2 decimal field can hold a value as small as -9999.99.

  • An integer raster can hold numbers as small as -32768, but often (due to an aversion to binary and an affinity for base 10) the value -9999 is used instead.

  • A float can hold numbers on the order of -10^(38). If you can't put an NaN in the field, either find the smallest float that will fit (which is a pain) or just use something like -10^(38) itself. For doubles, -10^(303) works fine, but so does -10^(38): it is sufficiently huge and negative to serve as a clear marker of a null value.

This rule is simple to remember, consistent, easy to apply, easy to document in a boilerplate fashion (for your metadata), and rarely leads to inadvertent errors (because the most negative number is usually so different from the data that its misuse as an actual value, instead of as a null, corrupts statistical summaries and other calculations enough to raise a flag that there is a problem).


Most rasters I've come across use -9999.0 for floating point data as a convention, and GDAL will use -dbl_inf when you're writing code for an image that doesn't have a nodata/dummy value. 8-bit RGB will usually use 0 0 0 or 255 255 255, or have an alpha or mask channel.

GML 3 coverages (for which there isn't a great deal of support at the moment, but that will change when the WCS 2 spec is ratified) has several dummy values that are represented as text such as "missing" and "withheld".

Im my experience any default tends to be domain-specific or vendor-specific. If you are the producer of data rather than the consumer, choose a number and stick with it and make sure your consumers are made aware of it.