[mapserver-users] NoData Gap between rasters - Tileindex Layer

[Rahkonen Jukka (Tike)]

Hi,

The image "two_separate_files.png" reveals the reason. If you look at the seam between the images the left side image and right side images do not share the same common canvas (pixels are not placed into same common grid). The area that you have marked as "000 nodata" has not received any image data from either image in warping. The warping algorithm has got a result like "51 % of this pixel is nodata, I stamp this pixel to nodata" or perhaps "the center of this pixel is nodata, thus the pixel is nodata". When the result is "nodata" for both left and right, there will be a seam.

Milo van der Linden suggests to try different resampling algorithms. It will not help because it does not affect the decision if the pixel is data or nodata. On the Mapserver side other resampling methods than the default Nearest neighbor can give some visual help by blurring the seam but it is not a real solution.

Solution that usually helps is the one I have posted to this list in 2014-08-29 and it is to force the individually warped images to use a common canvas by running gdalwarp with parameters -tr and -tap. You have answered that you tried it with -tr 0.36 0.36 -tap but that did not help. I left you alone then, sorry for that. By the way, is "two_separate_files.png" from this experiment? I suppose not.

I should have asked if 0.36 m is the native resolution of your original images. If the pixel size is less than the native one there may still be room for the double-nodata pixels. I have used -tr 0.5 -tap when my originals have 0.5 m resolution with perfect results.

I would have a new trial with -tr and -tap.  If that does not help there are two more things to try:
- Create a mosaic in the original SRS before warping. You can create a .vrt file with gdalbuildvrt without wasting any disk space. Run gdalwarp from the .VRT file and cut the results into tiles if you need them with gdalwart target extents parameter "-te xmin ymin xmax ymax".
- If -tap does not compute good aligned target extents you can compute them yourself. Here is Python code snippet that we used for several years before -tap options existed for widening the output extents to full meters
                           minmax = get_minmax(tm32_coords)
                           minmax_wider = [
                                                       (int(math.floor(minmax[0][0])), int(math.floor(minmax[0][1]))),
                                                       (int(math.ceil (minmax[1][0])), int(math.ceil (minmax[1][1]))),
                           ]

                           log("Extents (min,max): " + str(minmax), outfilename)
                           log("Widened extents (min,max): " + str(minmax_wider), outfilename)

However, the ultimate thing to do is re-consider if it is necessary at all to warp the original images into EPSG:3857. Mapserver warps pretty fast on-the-fly and I have not warped a single image after the introduction of support for different native projections in tileindex. See the -t_srs option http://www.gdal.org/gdaltindex.html. For utilizing this feature Mapserver 6.4 or higher is needed.

-Jukka Rahkonen-



Burkot wrote:

Dear MS Users

Please look at the attachement and maybe you will recognize the problem. I think some of you could have encountered this problem with one pixel gap between rasterfiles in tileindex layer?


Description:
I have a set of rasters which I warped to epsg:3857 projection using gdalwarp.
During the reprojecting the new raster had been rotated by small angle.
After that I created a tileindex shape file using gdaltindex and configured layer:
LAYER
        NAME "myname"
        TILEINDEX "tilindex.shp"
        TYPE RASTER
        OFFSITE 0 0 0
    END

On the result map I see the gaps between raster files in the layer. (See the attachment).
Mayby there is a option in gdalwarp command to extend the new image by making it 1 pixel widther? May by something like resampling method or algorithm?
Could you please pint me to the solution of this problem?

Thanks in advance

Bartek


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-users/attachments/20140910/e3fe06d3/attachment.html>