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
_______________________________________________
mapserver-users mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/mapserver-users
