That is a very interesting question you are raising. Thank you :-)<br><br>Two solutions come to mind:<br><br>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.<br>
A test of this is in the making...<br><br>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.<br>
<br>In your opinion, what would be the best work-around to solve this issue?<br><br>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.<br><br>-Jonas<br><br><br><div class="gmail_quote">On Tue, Aug 24, 2010 at 9:43 AM, Jukka Rahkonen <span dir="ltr"><<a href="mailto:jukka.rahkonen@mmmtike.fi">jukka.rahkonen@mmmtike.fi</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im">jonas nielsen <jonasln <at> <a href="http://gmail.com" target="_blank">gmail.com</a>> writes:<br>
<br>
><br>
><br>
</div><div class="im">> The original images that the overviews are built on are 10000 by<br>
10000 pixels.<br>
><br>
> And yes, the artifacts appear without reprojection.<br>
><br>
> -Jonas<br>
<br>
</div>Hi,<br>
<br>
I do also see such artifacts with Mapserver tileindex layers when<br>
zoomed far away so that the overviews are used. I have a slight<br>
feeling that it may come from subsampling when the resolution and<br>
image extents do not math exactly. With your images I would guess<br>
that the first overview levels up to 16 might work fine because<br>
the image extents can be filled exactly with the new subsampled pixels.<br>
<br>
samling theoretical<br>
level image width<br>
1 10000<br>
2 5000<br>
4 2500<br>
8 1250<br>
16 625<br>
32 312.5<br>
64 156.25<br>
128 78.125<br>
256 39.0625<br>
512 19.53125<br>
1024 9.765625<br>
2048 4.8828125<br>
<br>
I cannot imagine what GDAL is really doing at, let's say, redused<br>
level 128. Your whole image width could be covered with 78.125 pixels,<br>
each 12.8 meters wide. Obviously this is not possible. Either the pixel<br>
size must be a bit smaller or this overview level contains 79 pixels<br>
and thus it is a bit wider than the original image. If the latter is<br>
the case, what colour does the border pixels, which have the majority<br>
of their area off-site, get?<br>
<br>
I may be totally on the wrong track but this is what I have been<br>
wondering. Same looking but warp process related artifacts can be<br>
seen in figure 3 in article<br>
<a href="http://www.scangis.org/scangis2007/papers/r3_rahkonen.pdf" target="_blank">http://www.scangis.org/scangis2007/papers/r3_rahkonen.pdf</a>.<br>
<br>
Figures 4 and 5 show how we managed to remove them.<br>
<div><div></div><div class="h5"><br>
<br>
-Jukka Rahkonen-<br>
<br>
<br>
_______________________________________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/gdal-dev" target="_blank">http://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
</div></div></blockquote></div><br>