Your Gauss-Krueger projection uses +datum=potsdam. Up to 2012, this was hard coded in proj4 to a very unprecise value using a 3-parameter-transformation.
You find more exact values for 7-parameter transformations in this topic:
http://forum.openstreetmap.org/viewtopic.php?id=12723
There is an even better ntv2-grid transformation available here (take the binary), that has to be in the same folder as your application and data, unlsss you specify full pathnames.
To compare the different possible values, I made this test batch file:
echo epsg31467-epsg4326 >out.txt
cs2cs +init=epsg:31467 +to +init=epsg:4326 31467.txt >>out.txt
echo proj-Definition epsg >>out.txt
cs2cs +proj=tmerc +lat_0=0 +lon_0=9 +k=1 +x_0=3500000 +y_0=0 +ellps=bessel +datum=potsdam +units=m +no_defs +to +init=epsg:4326 31467.txt >>out.txt
echo proj-definition Qgis >>out.txt
cs2cs +proj=tmerc +lat_0=0 +lon_0=9 +k=1 +x_0=3500000 +y_0=0 +ellps=bessel +towgs84=582,105,414,1.04,0.35,-3.08,8.3 +units=m +no_defs +to +init=epsg:4326 31467.txt >>out.txt
echo proj-definition nadgrid >>out.txt
cs2cs +proj=tmerc +lat_0=0 +lon_0=9 +x_0=3500000 +y_0=0 +k=1.000000 +ellps=bessel +units=m +nadgrids=./BETA2007.gsb +wktext +to +init=epsg:4326 31467.txt >>out.txt
echo epsg31467-epsg3785 >>out.txt
cs2cs +init=epsg:31467 +to +init=epsg:3785 31467.txt >>out.txt
echo proj-definition Qgis >>out.txt
cs2cs +proj=tmerc +lat_0=0 +lon_0=9 +k=1 +x_0=3500000 +y_0=0 +ellps=bessel +towgs84=582,105,414,1.04,0.35,-3.08,8.3 +units=m +no_defs +to +init=epsg:3785 31467.txt >>out.txt
echo proj-definition nadgrid >>out.txt
cs2cs +proj=tmerc +lat_0=0 +lon_0=9 +x_0=3500000 +y_0=0 +k=1.000000 +ellps=bessel +units=m +nadgrids=./BETA2007.gsb +wktext +to +init=epsg:3785 31467.txt >>out.txt
echo epsg31467-epsg3857 >>out.txt
cs2cs +init=epsg:31467 +to +init=epsg:3857 31467.txt >>out.txt
echo proj-definition Qgis >>out.txt
cs2cs +proj=tmerc +lat_0=0 +lon_0=9 +k=1 +x_0=3500000 +y_0=0 +ellps=bessel +towgs84=582,105,414,1.04,0.35,-3.08,8.3 +units=m +no_defs +to +init=epsg:3857 31467.txt >>out.txt
echo epsg31467-epsg900913 >>out.txt
cs2cs +init=epsg:31467 +to +init=epsg:900913 31467.txt >>out.txt
echo epsg31467-proj900913 >>out.txt
cs2cs +init=epsg:31467 +to +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 +nadgrids=@null +wktext +over +no_defs 31467.txt >>out.txt
echo proj31467-proj900913 >>out.txt
cs2cs +proj=tmerc +lat_0=0 +lon_0=9 +k=1 +x_0=3500000 +y_0=0 +ellps=bessel +towgs84=582,105,414,1.04,0.35,-3.08,8.3 +units=m +no_defs +to +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 +nadgrids=@null +wktext +over +no_defs 31467.txt >>out.txt
with any sample Gauss-Krüger lon-lat coordinate pair in 31467.txt
Try reading the layers using rgdal::readOGR , this reads the projection automatically and is (IMO) more robust that readShapePoly.
Then if needed, run spTransform with one of your layers as the "to" option.
Best Answer
When applying a set of transformations and/or conversions through a PROJ pipeline inside the
-ctparameter of gdalwarp, the coordinates of the pixels are changed, but not the reference system of those coordinates.In order for the new coordinates to correspond to the same location on Earth as the previous ones, the target Spatial Reference System must also be modified through the
-t_srsparameter.The source geospatial location was already defined in the source file, through a geotransform matrix or control points, referenced to a source SRS. The set of operations from the source (in the file) to the destination (in the -t_srs parameter) SRS is overwritten with the -ct command, avoiding the search of the default operation within the PROJ database.
Therefore, to custom transform to a new SRS, it is necessary to define both
-ctand-t_srsparameters on the gdawarp command line.