Heng, > > > Hi Uwe, > > Thanks for your quick response as usual :) > > Yes, I had to use the "BIGTIFF=YES" option on some of these > large data to get the re-projection done, but did not need to > use this option on all the data which had this problem. The > word "large" was actually mentioned due to the fact that all > the data which do not have this "gap" problem after the > re-projection are smaller than the ones which have. If you > want, I can give you more details about the actual size of > those data tomorrow as I do not have access to the data at the moment. > > I actually can clearly see those "gaps" in FW OpenEV and in > one of our own tools (only for viewing). The gaps are always > there no matter I zoom in/out them in whichever way. Of > course, the gaps will become bigger if I zoom in the picture. > > The original data are actually provided in smaller tiles > (GeoTiff) and all I need to do this time is re-projecting the > data and displaying them as a whole dataset. However, after I > did the re-projection on those tiles separately, there appear > to be black lines around those tiles when displaying them in > one view/window (even after merging them with GDALWARP > command. Shall I use the option "skip_nosource=yes" to mosaic > the tiles in the GDALWARP command?). And this was why I chose > to merge the smaller tiles first and then re-project the > merged large dataset. > if these gaps are one or two pixel in size and around the tile boundaries, it is possible that they are caused by rounding problems during transformation. I don't know anything about your data, but If they are RGB try to use another interpolation algorithm like "-r cubic". The command you posted uses "-r near". This can cause those black pixels.
Uwe
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
