W dniu 07.10.2009 03:35, Adam Ratcliffe pisze: > I ran into a problem when warping my merged SRTM data that the output > image was greater than the 4GB GeoTIFF file size limit. To overcome > this problem I generated 2 output images, one for the North Island of > New Zealand and the other for the South Island. I did this using the > -te option to gdalwarp to specify the extents of the output file, color > relief and hillshade images were generated from these warped images. > > Problem is I'm seeing a dark band where the 2 sets of images meet, this > can be seen in this > screenshot: http://test.geosmart.co.nz/images/map-border.png Looking at > the hillshade image there appears to be a black 1px border around the > image. > > Could this be the source of the problem? Has anybody else seen and > found a resolution for the issue? >
When You are using hillshade rasters without composition, solution is pretty simple, just increase overlaping so that two adjacent tiffs has at least few px common area. hgt files already have such 1px overlaping, not sure how You merge them, but just in case add more. Problem also could be from misaligned resolution (-tr parameter in gdal_warp command), due to integer rounding of raster position. Using overlapping should fix black border in this case too, but some visible border could be still possible (misalignment). When -tr is set to exact power of 2 of output map resolution, at least rounding error will be the same for all points of rasters, and two adjacent rasters will join. I use tr value as described in mentioned earlier thread: http://www.nabble.com/My-patches-for-hill-shading-td22215531.html#a22799823 If using osm/google like zoom levels, it should be as one of: tr = 6378137*2*Pi/2^n where n is such, that tr is closest to Your desired resolution (90 is theoretical resolution of SRTM3, 30 for SRTM1). I use n=19 so tr = 76.437028295. This way one pixel of raster is one pixel of output image at zoom level 11 of google/osm projection/tiling scheme. It helps scaling on other zooms (just power of 2), and prevent different rounding errors for each raster (also helps with upscaling and adjacent output tiles alignment). So when warping from hgt's lat/lon projection to google/osm mercator projection I use: > gdalwarp -of GTiff -srcnodata 32767 -dstnodata 32767 -s_srs \ > "+proj=latlong +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 \ > +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgri...@null +no_defs +over" \ > -t_srs "+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 \ > +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgri...@null +no_defs +over" \ > -rcs -order 3 -tr 76.437028295 76.437028295 -wt Float32 -ot Float32 \ > srtm.tif warped.tif I use -s_srs to override projection parameters from hgt format, to avoid ellipsoid reprojection, that gave me strange offset. srtm.tif is simply merge of some selected hgt files. Not sure, gdal should round them properly to raster resolution, however for tests with multiple rasters I used exact values to -te parameter due to problem described below. Use gdalinfo to check output tiff parameters: if pixel resolution matches (Pixel Size) and if there is enough overlapping(Corner Coordinates). If using composing effect, there is additional problem, that margin is not an option, rasters must meet without overlapping, to avoid double effect area. In this case rasters must be ideally joined (one edge end is another one start). Additionally I had to patch earlier mapnik, to avoid additional rounding problems (it's already committed): http://trac.mapnik.org/ticket/295 But in Your case it isn't necessary as described at the beginning. -- Marcin Rudowski _______________________________________________ Mapnik-users mailing list [email protected] https://lists.berlios.de/mailman/listinfo/mapnik-users
