Opened 13 years ago

Closed 9 years ago

#3778 closed enhancement (invalid)

gdal_contour dtm input signed / unsigned flag

Reported by: moellney Owned by: warmerdam
Priority: normal Milestone:
Component: Utilities Version: svn-trunk
Severity: normal Keywords: gdal_contour signed unsigned
Cc:

Description (last modified by moellney)

Sometimes we have files that produce negative dtm values at sea-level but put unsigned integer data in png / tiff file format.

When e.g. producing a contour at 100m we get a log of small circle at the sea, because gdal_contour has no chance to see, that the extremle high numbers are negative values in effect (due to the coding of negative values in binary notation).

So how to about a flag that tells gdal_contour to reinterpret the binary data singed instead of unsigned?

Attachments (1)

Hongkong_test1.tif (170.4 KB ) - added by moellney 13 years ago.
DTM Data received from SRTM NASA WMS server saved as tiff.

Download all attachments as: .zip

Change History (7)

by moellney, 13 years ago

Attachment: Hongkong_test1.tif added

DTM Data received from SRTM NASA WMS server saved as tiff.

comment:1 by Even Rouault, 13 years ago

Resolution: invalid
Status: newclosed

The TIFF file isn't valid if it is meant at having signed values. Namely the value of the SAMPLEFORMAT tag is 1 (SAMPLEFORMAT_UINT) in your example, whereas it should be 2 (SAMPLEFORMAT_INT).

This can be corrected by example with the tiffset utility of libtiff

tiffset -s 339 1 2 Hongkong_test1.tif

in reply to:  1 comment:2 by moellney, 13 years ago

Description: modified (diff)
Resolution: invalid
Status: closedreopened

Replying to rouault:

The TIFF file isn't valid if it is meant at having signed values. Namely the value of the SAMPLEFORMAT tag is 1 (SAMPLEFORMAT_UINT) in your example, whereas it should be 2 (SAMPLEFORMAT_INT).

This can be corrected by example with the tiffset utility of libtiff

tiffset -s 339 1 2 Hongkong_test1.tif

Thanks for the hint. In tiff is seems to be possible to signal signed or unsigned. Your example works and gives nice results with gdal_contour.

But do you know if png supports signed integer?

Let me cite from the capabilities file of the nasa wms:

<Layer queryable="0">
      <Name>worldwind_dem</Name>
      <Title>SRTM derived global elevation, 3 arc-second</Title>
      <Abstract>
	A global elevation model, prepared from the 3 arc-second SRTM dataset by filling some
        of the problem areas. Prepared by the NASA Learning Technologies.
	The default style is scaled to 8 bit, non-linear.
	It is possible to request the elevation data in meters by the short_int tyle and
        requesting PNG format. The resulting PNG file will be a unsigned 16 bit per pixel
        image. The values are then the elevation in meters.
	Values are signed 16 bit integers, but PNG will present them as unsigned, leading to a 
        few areas with very large values (65000+)
	For elevation values in feet, request PNG format with the style feet_short_int.
      </Abstract>

comment:3 by Even Rouault, 13 years ago

No, PNG only supports unsigned 16 bit. As they acknowledge, the NASA stuff is a hack. You'll have to write some code to reinterpret the values above 32768 as negative values and write that to a proper format (for example signed TIFF).

I really do think this isn't a GDAL bug and, personnaly, I wouldn't been keen on adding ugly hacks for that in the GDAL utilities when there are formats that are designed to handle properly signed 16 bit data such as TIFF. Others might have different opinions of course...

comment:4 by warmerdam, 13 years ago

I concur with Even. This is not a gdal_contour problem. At best it might be nice to offer some sort of clamping or remapping options in gdal_translate to make it easier for people to fix up such data issues.

in reply to:  4 comment:5 by moellney, 13 years ago

Replying to warmerdam:

I concur with Even. This is not a gdal_contour problem. At best it might be nice to offer some sort of clamping or remapping options in gdal_translate to make it easier for people to fix up such data issues.

I also understand, that the coding method in the NASA implementation is not appropriate, but I do not see a chance to talk NASA into using an other format....

So I would support extending gdal_translate to a fixing tool for such cases and leave gdal_contour small and simple (regarding it's parameters :-)

comment:6 by Jukka Rahkonen, 9 years ago

Resolution: invalid
Status: reopenedclosed

If the conclusion was that this is not a gdal_contour problem then I am closing the ticket. If it still feels necessary, start a discussion on gdal-dev mailing list about the best method for fixing such data with gdal_translate or gdal_calc or something else.

Note: See TracTickets for help on using tickets.