[gdal-dev] Re: Artifacts when presenting WMS based on a number of adjoining vrt files with overviews

[jonas nielsen]

That is a very interesting question you are raising. Thank you :-)

Two solutions come to mind:

1: Change the parameters of gdaladdo to something that will produce an
integer division with the input data size. In this case, with 100k by 100k
px, that means it will no longer be multiples of two.
A test of this is in the making...

2: Keep using multiples of two for gdaladdo, but only as far as they produce
an integer division. When this point is reached a new "solid" image can then
be created with MapServers shp2img function. More overviews can then be
built on this as required. This potentially allows us to gather more and
more 10 km by 10 km blocks in these shp2img outputs, which should be good
for display performance, as fewer files needs to be accessed for display of
the entire dataset. It also means that both GDAL and MapServer are working
on the images several times over, and the impact of this on image quality is
unknown. Also, great care must be taken when making the mapfile for final
display in MapServer.

In your opinion, what would be the best work-around to solve this issue?

No matter what we do, we will probably have to use shp2img to build a
complete view of the entire dataset at the top level, to reduce file-access
and achieve good performance.

-Jonas


On Tue, Aug 24, 2010 at 9:43 AM, Jukka Rahkonen
<jukka.rahkonen at mmmtike.fi>wrote:

> jonas nielsen <jonasln <at> gmail.com> writes:
>
> >
> >
> > The original images that the overviews are built on are 10000 by
> 10000 pixels.
> >
> > And yes, the artifacts appear without reprojection.
> >
> > -Jonas
>
> Hi,
>
> I do also see such artifacts with Mapserver tileindex layers when
> zoomed far away so that the overviews are used. I have a slight
> feeling that it may come from subsampling when the resolution and
> image extents do not math exactly.  With your images I would guess
> that the first overview levels up to 16 might work fine because
> the image extents can be filled exactly with the new subsampled pixels.
>
> samling theoretical
> level   image width
> 1       10000
> 2        5000
> 4        2500
> 8        1250
> 16        625
> 32        312.5
> 64        156.25
> 128       78.125
> 256       39.0625
> 512       19.53125
> 1024       9.765625
> 2048       4.8828125
>
> I cannot imagine what GDAL is really doing at, let's say, redused
> level 128. Your whole image width could be covered with 78.125 pixels,
> each 12.8 meters wide. Obviously this is not possible. Either the pixel
> size must be a bit smaller or this overview level contains 79 pixels
> and thus it is a bit wider than the original image. If the latter is
> the case, what colour does the border pixels, which have the majority
> of their area off-site, get?
>
> I may be totally on the wrong track but this is what I have been
> wondering. Same looking but warp process related artifacts can be
> seen in figure 3 in article
> http://www.scangis.org/scangis2007/papers/r3_rahkonen.pdf.
>
> Figures 4 and 5 show how we managed to remove them.
>
>
> -Jukka Rahkonen-
>
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20100824/2b438ace/attachment.html