2007.01.17 16:52 "RE: [Tiff] Elevation Data", by Ed Grissom

In a previous message, Joris said:

Though, still, have you seen many actual use of these tags in the implied sense? If you've test images that do use them this way, I'd be very grateful for a copy.

No, unfortunately, in the GIS/RemoteSensing community, we are all just standing on the sidelines waiting for someone else to go first.

I have some 32bit floating point data that I am not allowed to share, but it does not use any of the min/max tags. I do not know what software was used to create it either.

In any case, when it comes to a recommendation for writers, would you agree that recommending them to stick with the 'intrinsic' range of the samples, as I explained it, is best and most likely to lead to good interchange (as far as there is interchange of floating point image data, at all)?

I don't mind such a recommendation as long as folks don't think they _have_ to transform their data.

We will rarely see a 0.0 to 1.0 range on elevation data. Typically, elevation data will be stored in either feet or meters and will be a floating point number within a limited range (for instance, the (USA) State of Tennessee should have no elevations below 50ft, nor above 7000ft). I would want to store this _as_collected_ and put the real min and max in the SMin and SMax values. I don't want to scale and descale the data to a 0.0 to 1.0 range. Especially since there is no STANDARD way of storing the scale and bias in an approved tag.

When using meters as a unit, most elevation data for earth would fall between +/-10,000.

When using feet as a unit, most elevation data for earth would fall between +/-30,000.

If the data does not have a "measured in the real world" interpretation, then a 0.0 to 1.0 range makes more sense as a default way to represent it.

We currently are using Min/Max as a valid range (if they are present and make sense) in violation of the spec for 16 bit data. I had not looked at the spec for SMin/SMax closely before today, but I am going to start using these in preference to Min/Max, since they do appear to do what I want.

Anyone else want to come along?

--
ed grissom
ed.grissom@intergraph.com