All too frequently we get a comment or question from someone downloading lidar data using the Data Access Viewer that says “The solid black tiff file included in the zip file for point cloud is useless.” I prefer to avoid wasting people’s time (and my CPU cycles) with something they can’t use, especially when that TIFF is the default choice, so I’m going to review what’s going on.
Why is the TIFF Black and White?
There are two possible issues that can lead to seeing a TIFF file with only black and/or white. The first thing to understand is that the TIFF file with elevation values is different than the typical imagery TIFF files you may be used to working with. It has floating point values. That means a given pixel in the file may contain something like 3.28 to represent a height of 3.28 meters. The default program for handling TIFF images that came with your computer probably have no idea what to do with that. They are expecting TIFF files with red, green, and blue integer bands, or perhaps a single band with a color table. Below are two software packages showing the same TIFF file. The Windows Photo Viewer on the left displays what looks like black and white and there isn’t much you can do to change that. A program expecting geospatial data (e.g. a remote sensing or GIS program) can apply a color map to the range of values and look like the image on the right.
So, step one is make sure you’re using a software package that understands your data. The Windows Photo Viewer probably is interpreting the the floating point values but it doesn’t know how to do anything but put a greyscale interpretation on the range it sees.
This brings us to the the second issue. For a lot of geospatial data, and particularly coastal DEMs, you need a way to indicate a “nodata” value where measurements couldn’t be made. A TIFF doesn’t have a way to indicate that in the standard specification. Common approaches to handle it are to use an IEEE Not a Number (NaN) value or to hope the non-standard tag that GDAL uses for missing data is sufficiently wide-spread that it will work. Some people do both. In this particular case, the GDAL nodata value is -999999. I think the Windows Photo Viewer is actually picking up on that, otherwise those somewhat dark grey areas in the marsh would be white as it scaled between -999999 and about 5 meters. If the IEEE NaN was used and the program didn’t understand that, the image might truly look black and white. You might see this even in some high-end GIS packages until you run statistics on the image so it can figure it out.
Why Only Floating Point?
Some people are probably looking for an elevation map that is a simple image that is already colored. A single band 8-bit image with a color map that looks pretty. We used to offer that, but found that it caused more problems than it solved. Since the true elevations weren’t there, it couldn’t be used for much analysis, and invariably people would pick the wrong TIFF option. Another issue is that we had to apply the color map in an automated fashion based on the values in the image. This resulted in a color map that was often not quite what was desired and the colors wouldn’t represent the same values between adjacent tiles. There are free and open source packages that will read the floating-point TIFFs correctly and allow the user to create what they want. An earlier GeoZone post showed an example of that.
Be Careful What You Ask For
I mentioned that the TIFF was the default choice when downloading lidar from Digital Coast. That might seem odd since lidar should be a point cloud and the TIFF is a raster DEM. We believe most people can work with a DEM more easily than the point cloud, hence it’s the default. The system can certainly deliver the point cloud. You simply need to select Point as your output product as shown below.
You also need to pay some attention to the data set titles. We’re starting to put more of the pre-made DEMs into the system because they have value. They often have had some manual cleaning applied and used breaklines to eliminate some interpolation artifacts that you’ll see in the automated DEMs made from the point cloud. The downside is that changes in projection will cause distortion that won’t be in the DEMs made from the point cloud (the points are reprojected before interpolating). How do you tell the difference? The pre-made DEMs will have either DEM or Digital Elevation Model in the title and you’ll have different options in the check-out. This is a big enough topic that it probably warrants it’s own post, along with a discussion of the new image services. In the meantime, make sure your software understands what you’re feeding it.