# Is there a standardized or “most used” dummy Z value?

Creating and importing both 2D and 3D data, I have many times encountered the situation where I have no Z value for a coordinate set, that the value of a Z coordinate seems out of range (like -99, -9999, -inf or similar) or that I need to create a dummy Z coordinate.

I know that the answer to my question is:

"Just use a value which is definitely out of range in your case."

But that answer set aside I wonder if the GIS community has a standardized or most frequently used value for a dummy Z coordinate?

-

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).

-

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.

-
+1 Most ESRI products, as well as most other software, will read nulls in numerical dBase fields as zeros. That's deadly, so it's usually important to use an explicit null coding in .dbf files (which includes shapefiles). – whuber May 17 '11 at 16:09

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.

-

I would use NaN because mathematical operations will produce other NaNs or throw exceptions. That way you can detectvearly that you are messing up because you are using a bogus value

-
NaN would be fine for calculations (with floating point values), but you can't store NaN in a many databases or GIS data formats – geographika May 17 '11 at 16:05
+1 @geographika is correct. Nevertheless, the point about using a value that will mess up calculations is an excellent one. – whuber May 17 '11 at 16:10
for integers you can have NaNs: numeric_limits<int>::quiet_NaN() – Ragi Yaser Burhum May 18 '11 at 4:37
Also, my recommendation was for the usage of NaN was as it relates to the Z value inside the geometry. So regardless of whether the value is in a database or not, IMHO it should be serialized with the geometry - so it should just work... – Ragi Yaser Burhum May 18 '11 at 4:42