[gdal-dev] gdalwarp makes landcover files blocky when shrinking pixel size

[John Twilley]

After retrieving the files and building VRTs from them, I run the
following gdalwarp commands:

gdalwarp -q -multi -t_srs "+proj=aea +datum=NAD83 +lat_1=29.5
+lat_2=45.5 +lat_0=23 +lon_0=-96 +x_0=0 +y_0=0 +units=m" -tr 6 6 -te
2002944 2271744 2016768 2288640 \
 -srcnodata -340282346638528859811704183484516925440 -dstnodata 0
ND302HT.vrt ND302HT.tif
gdalwarp -q -multi -t_srs "+proj=aea +datum=NAD83 +lat_1=29.5
+lat_2=45.5 +lat_0=23 +lon_0=-96 +x_0=0 +y_0=0 +units=m" -tr 6 6 -te
2002944 2271744 2016768 2288640 \
 -srcnodata 255 -dstnodata 11 L0102HT.vrt L0102HT.tif

The only differences between the lines are the nodata values.

Jack.
--
mathuin at gmail dot com



On Thu, Jan 26, 2012 at 22:49, Dmitry Baryshnikov <polimax at mail.ru> wrote:
> 27.01.2012 3:39, John Twilley пишет:
>>
>> I am working with elevation and landcover data downloaded from the
>> USGS.  I use gdalwarp to convert the data to a much smaller pixel. The
>> elevation data works very nicely with cubic resampling, but the only
>> resampling that works at all for the landcover data is
>> nearest-neighbor and that's very blocky.  When I last worked with
>> landcover data, I used a majority algorithm which produced smoother
>> output -- but that algorithm is not implemented in gdalwarp.
>> I am looking over the source to gdalwarp to see how hard it is to add
>> a new algorithm.  Other than that, though, what options are available
>> to me?  Thanks in advance!
>> Jack.--
>> mathuin at gmail dot com
>> _______________________________________________
>> gdal-dev mailing list
>> gdal-dev at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>>
>>
> Hi John,
>
> That is your command line string for gdalwarp?
>
> Best regards,
> Dmitry
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev