W dniu 22.02.2010 19:12, Philip Howarth pisze: > Hi > > I am using the Raster symbolizer to include a colour relief file as > background. > > I can generate the georef'd background files from either SRTM3V4 tifs (5 > degree squares) or ASTER tifs (1 degree squares) using exactly the same > python script. > > Viewing the resulting files in QGIS or other tools - the coordinates of > boundaries and features are correct. > > Mapnik produces maps when I use either the ASTER or the SRTM derived tif > as background. My problem is that the SRTM derived background is > displaced by about 0.06 degrees to the North. Interestingly, East/West > positioning appears to be correct. >
In Your case, I'm not sure how it works, that You are using WGS84 image and passing to mapnik coordinates in mercator. If raster is WGS84 and You generate map in Mercator, then it needs to be warped at some point and I believe mapnik can't do that with rasters. Maybe Your problem is very simple: You are using raster in wrong projection not matched with one used in mapnik. In effect on upper and lower raster edge, everything should be quite fine, but in the middle, there should be some misalignment in north/south direction. So You need to transform Your tiff to Mercator before using in Mapnik, and then it will be visible even when using gdal plugin. Now I thing it tries to draw raster near: 10,50 but in mercaator, and this is near Africa. Beside that, I had problem with strange offset when first started with hillshading, but in my case at ~50 deg North it was: ~20km (0.2deg). After some time I found out, that this kind of error is connected with ellipsoid reprojection. SRTM is in WGS84 that uses ellipsoid (6378137,298.257223563) and spherical Mercator is using sphere, so besides simple converting coordinates gdal also did ellipsoid->sphere reprojection and this gave offset in south/north direction. So in short it works like that: 1. source coordinates in degrees converted to XYZ using WGS84 ellipsoid 2. XYZ converted to degrees using sphere parameters 3. degrees converted to Mercator My gdal_warp magic command, to avoid such problem was: > gdal_merge.py -v -o ../srtm.tif *.hgt > 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.4370282852 76.4370282852 -wt Float32 -ot Float32 \ > srtm.tif warped.tif > ./hillshade warped.tif hill_8.tif -z 2 So I force srtm to be treated as simple latlon on same sphere as output mercator, to avoid step 1 and 2. But it is quite different from Your case. I describe it, because it is still quite confusing for me. Some links: http://lists.maptools.org/pipermail/proj/2007-March/002852.html http://www.mail-archive.com/[email protected]/msg00564.html http://www.mail-archive.com/[email protected]/msg01051.html -- Marcin Rudowski _______________________________________________ Mapnik-users mailing list [email protected] https://lists.berlios.de/mailman/listinfo/mapnik-users
