-
2007.01.17 02:57 "Re: [Tiff] Elevation Data", by Bob Friesenhahn
-
2007.01.17 08:07 "Re: [Tiff] Elevation Data", by Joris Van Damme
- 2007.01.17 15:24 "RE: [Tiff] Elevation Data", by Ed Grissom
-
2007.01.17 16:27 "Re: [Tiff] Elevation Data", by Frank Warmerdam
-
2007.01.17 19:00 "Re: [Tiff] Elevation Data", by Joris Van Damme
-
2007.01.17 21:51 "Re: [Tiff] Elevation Data", by Frank Warmerdam
-
2007.01.17 19:26 "RE: [Tiff] Elevation Data", by Ed Grissom
- 2007.01.17 16:20 "Re: [Tiff] Elevation Data", by Joris Van Damme
- 2007.01.17 20:22 "Re: [Tiff] Elevation Data", by Joris Van Damme
- 2007.01.17 20:52 "Re: [Tiff] Elevation Data", by Joris Van Damme
-
2007.01.17 19:26 "RE: [Tiff] Elevation Data", by Ed Grissom
-
2007.01.17 21:51 "Re: [Tiff] Elevation Data", by Frank Warmerdam
-
2007.01.17 19:00 "Re: [Tiff] Elevation Data", by Joris Van Damme
- 2007.01.17 22:18 "Re: [Tiff] Elevation Data", by Bob Friesenhahn
-
2007.01.17 08:07 "Re: [Tiff] Elevation Data", by Joris Van Damme
- 2007.01.17 03:35 "Re: [Tiff] Elevation Data", by Frank Warmerdam
- 2007.01.17 08:00 "Re: [Tiff] Elevation Data", by Joris Van Damme
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