[gdal-dev] Having difficulties using gdalwarp

[Frank Warmerdam]

On Wed, Oct 3, 2012 at 5:06 PM, Simon Knapp <sleepingwell at gmail.com> wrote:
> Hi List,
>
> This is my first post here so please let me know if my question would
> be better placed elsewhere.

Simon,

This is a good place for the question.

> I am struggling with re-projecting integer
> grids using gdalwarp and would appreciate some help.
>
> I have two grids containing land use data at different scales:
>
> grid 1) a 50m (esri binary) grid in albers,
> grid 2) a 1km (ascii) grid in geographics.
>
> I would like to project these to a common coordinate system with
> resolution corresponding to grid 1 so I can perform cross tabulations
> and alike. I have tried going in both directions
>
> The calls I have tried are:
>
>
>
> call 1) re-project and re-sample grid 2 to the same projection as grid
> 1. I have obtained the parameters from the property pages of grid 1 in
> QGIS:
>
> gdalwarp ^
> -t_srs "+proj=aea +lat_1=-18 +lat_2=-36 +lat_0=0 +lon_0=132 +x_0=0
> +y_0=0 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs" ^
> -te -1888000 -4847000 2122000 -1010000 ^
> -tr 50 -50 ^
> -dstnodata -32768 ^
> nlum.asc nlum_warped.tif
>
>
> call 2) re-project grid 1 to have the same projection as grid 2. Here
> I have not specified the resolution and was planning to also re-sample
> grid 2 to the resolution of the result. I get the parameters from the
> QGIS property pages of grid 2:
>
> gdalwarp ^
> -t_srs "+proj=longlat +ellps=WGS84 +towgs84=0,0,0,0,0,0,0 +no_defs" ^
> -te 112.505 -44.0055 154.005 -9.995 ^
> -dstnodata -32768 ^
> clumfill clum_warped.tif
>
>
>
> In the first call I get 24Gb of complete rubbish. When I open the
> result in QGIS noting is shown (visually) and the cell values contain
> what appears to be uninitialised junk.
>
> In the second call, I get a grid that looks similar to what I want,
> but the cell value ranges are different ([100, 663] in the input and
> [0, 663] in the result) and the histograms are different. I thought
> that by (implicitly) choosing nearest neighbour the values in the
> output must be a subset of those in the input.
>
> Can anyone suggest what might be going wrong?

In the second case, I imagine the zeros represent
nodata pixels - that is pixels for which there was no source data
due to the change of coordinate system.

It is hard to know what went wrong in the first case.  Is
the source file small enough that you could make it available
for me to test with?

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Software Developer