How to get hypsometric curve from elevation data?

I have my elevation data but cannot make an attribute table from it and so I'm not sure how to get any of that data into a table in order to make a hypsometric curve.

-

The raster is stored in floating point format as individual values in each cell; therefore it has no attribute table. An effective solution is to discretize the values and convert them to integer format. This creates an attribute table which, when plotted, will yield a histogram. Its cumulative sums are the hypsometric curve.

The appearance of the hypsometric curve (in CDF form) for this sample DEM (a portion of Illinois available at http://exampledata.wolfram.com/ArcGRID.zip) varies with the fineness of the value discretization. The following images use bins of 5, 1, and 1/5 meters, respectively. As you can see, one can obtain a precise curve using moderately coarse bins.

Discretizing a grid involves two operations which can be done in one step: divide by the bin width and truncate (or round, if you prefer). For example, elevations in meters can be discretized into 0.1 meter increments via division by 0.1 followed by truncation, as in

``````Int( [elevation] / 0.1 )
``````

This syntax, or something quite close to it, would be used in almost any version of ArcGIS (and in many other raster GISes as well).

-
If elevations can be both positive and negative, see whether your version of ArcGIS supports a `Floor` function, because some `Int` implementations truncate towards 0 rather than downward, which would double the width of the bin containing 0 (an undesirable result). – whuber Oct 18 '11 at 16:18
@Kirk That's a good idea, but my experience with ESRI software and statistical calculations leads me to mistrust it. Where's the detailed documentation? E.g., exactly what kind of sampling procedure is used? Where's the evidence that it gets the right result? And if there is such evidence--say, through extensive user testing and reverse-engineering--we have to throw it all away and start over with the very next software patch. – whuber Oct 18 '11 at 22:42
Well, I was going to suggest plugging in your own IBinFunction2, but I see it says "This interface is not intended to use by outside developers." Oh well. – Kirk Kuykendall Oct 19 '11 at 2:29
I would echo @whuber; ESRI's statistics are suspect. We have been complaining to tech support for two years that their percentiles/quartiles are being calculated incorrectly and are not even consistent within the software. We have empirically demonstrated to them that they are not "exact" nor "interpolated". Their response is that they are "sampling the data" but, will not reveal details. – Jeffrey Evans Mar 30 '14 at 0:25
@Jeffrey I met with ESRI representatives in 2006 and presented this issue (among many others) to them. At the time I had documented three different calculations of standard deviations within ArcGIS, of which at least one was clearly a bug. I like and use ArcGIS for its strengths, but because of this kind of behavior I am compelled to conclude that statistical analysis--of any kind--is not among them. – whuber Mar 30 '14 at 17:37

I normally use R for this. You can read GDAL raster data sets using `rgdal` (from CRAN), then build an empirical cumulative distribution for the elevation values using `ecdf` (built-in).

For example, I have my DEM in a GeoTIFF file, in R use:

``````library(rgdal)