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

[Etienne Tourigny]

In my opinion the "mode" (majority) algorithm should be implemented
into gdalwarp, as it would solve re-gridding (to finer or coarser
grids) of thematic/discrete data.

The gdaladdo work-around (for coarser grids) is not very intuitive,
and does not work for finer re-gridding.

As there is existing code for gdaladdo, how hard would it be to adapt
it to warping operations?

I am not sure that the other gdaladdo methods are worth using in
gdalwarp though...

gdaladdo: nearest
(default),average,gauss,cubic,average_mp,average_magphase,mode:
gdalwarp: near (default), bilinear, cubic, cubicspline, lanczos:

regards,
Etienne

On Fri, Jan 27, 2012 at 6:15 PM, John Twilley <mathuin at gmail.com> wrote:
> I believe my landcover data is a classified raster.  It has a color
> table and uses values like 11 for water and 12 for ice.
>
> The majority algorithm I implemented that looked okay in the old code
> used a number of the nearest neighbors.  Taking just one nearest
> neighbor made the blocky images I described in my original message.
> If gdalwarp had gdaladdo's mode algorithm, would that do a better job
> than the nearest-neighbor algorithm?
>
> When I tried using pct2rgb.py on the VRT, then running the gdalwarp
> with a variety of resampling methods, then using rgb2pct.py on the
> resulting output (referencing the VRT for the palette), the output was
> filled with speckles.  For example, when a finger of sand poked out
> into the water, the various methods created many tiny one-pixel lakes
> and islands.  Not quite right.
>
> Jack.
> --
> mathuin at gmail dot com
>
>
>
> On Fri, Jan 27, 2012 at 11:27, Chaitanya kumar CH
> <chaitanya.ch at gmail.com> wrote:
>> John,
>>
>> You are right. gdaladdo is not for creating higher resolution images. I
>> thought you needed the opposite.
>> I assume your landcover data is a classified raster. Classified data is
>> usually zoomed in with nearest neighbor interpolation. Unless you fiddle
>> with the interpolation window, the majority algorithm is pretty much the
>> nearest neighbor while zooming in.
>>
>> If you want, you can convert the image into an RGB using pct2rgb.py and work
>> with the RGB image.
>>
>>
>> On Fri, Jan 27, 2012 at 11:30 PM, John Twilley <mathuin at gmail.com> wrote:
>>>
>>> I've never seen gdaladdo -- neat command!  Alas, the overviews are the
>>> wrong way 'round -- I don't need to zoom out, I need to zoom in.
>>> gdaladdo doesn't handle fractional scale values well, so I can't make
>>> something bigger out of something smaller like I can with gdalwarp.
>>>
>>> Jack.
>>> --
>>> mathuin at gmail dot com
>>>
>>>
>>>
>>> On Thu, Jan 26, 2012 at 20:01, Chaitanya kumar CH
>>> <chaitanya.ch at gmail.com> wrote:
>>> > John,
>>> >
>>> > Try gdaladdo [1] with the resampling algo set to 'mode'. If you use the
>>> > -ro
>>> > option, it will create an external overview. Check your output with
>>> > different combinations of levels.
>>> >
>>> > [1]: http://www.gdal.org/gdaladdo.html
>>> >
>>> > On Fri, Jan 27, 2012 at 5:09 AM, John Twilley <mathuin at gmail.com> wrote:
>>> >>
>>> >> 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
>>> >
>>> >
>>> >
>>> >
>>> > --
>>> > Best regards,
>>> > Chaitanya kumar CH.
>>> >
>>> > +91-9494447584
>>> > 17.2416N 80.1426E
>>
>>
>>
>>
>> --
>> Best regards,
>> Chaitanya kumar CH.
>>
>> +91-9494447584
>> 17.2416N 80.1426E
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev