作为示例，我将使用以下图块http://a.tile.openstreetmap.org/3/4/2.png并将其保存为“ 4_2.png”。
这种瓷砖的WGS84坐标可以被计算或读取那里通过点击对应的瓦片：
0 66.51326044311185 45 40.97989806962013 (West North East South)如何正确地对瓷砖进行地理参考（使用gdal生成地理坐标或其他地理参考格式），以便：
- 不需要拉伸位图（= Geotiff中的像素与原始位图中的像素完全相同）
- 生成的图像将在GIS查看器/编辑器中的正确位置打开（例如在TatukGIS Free Viewer中）？
（于2011年9月19日编辑，以使我的问题更清楚并包括我的结论）
我的结论是：
我首先说第三个想法（见下文）是正确的。我在GIS Viewer中打开了Geotiff，并将显示的坐标与预期的坐标进行了比较。从第二个想法出来的Geotiff似乎向北移动了2个像素。这就是为什么我认为想法3（或4）是正确的原因。
但是，如果您尝试使用更高缩放级别的图块，则想法3之外的地标肯定会向南移动。在缩放级别3的图块上比较坐标是愚蠢的。在此缩放级别上的国家/地区边界被简化了，以致于比较不能给出良好的结果。
Dan S.是对的，图块的图像已经在EPSG：3857中。第二个想法就是正确的想法（并且在高缩放级别上也能提供良好的效果）
第一个想法：EPSG：4326
WGS84坐标的EPSG代码是EPSG：4326。因此，我仅使用WGS84坐标即可使用gdal_translate将瓷砖作为geotif进行地理参考：
gdal_translate -of Gtiff -co tfw=yes -a_ullr 0 66.51326044311185 45 40.97989806962013 -a_srs EPSG:4326 4_2.png t4326.tif生成的地图显示在正确的位置，但我担心投影不正确，并且瓷砖中间可能会有偏移。在尝试了很长时间以通过使用gdalwarp重新投影地图进行检查之后，我下载了Global Mapper的演示版，似乎是这种情况（与想法3相同的边框，但在磁贴内部发生了偏移）。应该拉伸图像以使用EPSG：4326坐标。
第二个想法：EPSG：3857
此图块使用“网络墨卡托”投影（即Google地图投影），现在具有EPSG代码：EPSG：3857（别名EPSG：900913）。我只是使用gdaltransform转换坐标：
gdaltransform -s_srs EPSG:4326 -t_srs EPSG:3857
0 66.51326044311185
0 10018754.1713946 0
45 40.97989806962013
5009377.08569731 5009377.08569731 0我以米为单位的坐标是：
0 10018754.1713946 5009377.08569731 5009377.08569731 (West North East South)现在，我可以使用gdal_translate生成一个geotiff：
gdal_translate -of Gtiff -co tfw=yes -a_ullr 0 10018754.1713946 5009377.08569731 5009377.08569731 -a_srs EPSG:3857 4_2.png t3857.tif我的印象是，这是不正确的，因为地图的边界向北移动。这似乎是正确的想法。
第三个想法：EPSG：3857到EPSG：4055
我读到“网络墨卡托”使用WGS84坐标，但认为它们好像是球形坐标。由于大地纬度和地心纬度之间的差异（有关纬度，请参见Wikipedia），椭圆形或球面上的纬度值将不同。我发现EPSG：4055是基于WGS84的球体上球坐标的代码。
将坐标转换为EPSG：4055：
gdaltransform -s_srs EPSG:4326 -t_srs EPSG:4055
0 66.51326044311185
0 66.3722684317026 -17964.0621483233
45 40.97989806962013
45 40.7894557844857 -9152.84527519904相应的球坐标为：
0 66.3722684317026 45 40.7894557844857 (West North East South)然后，我就像那些坐标仍在椭球上（EPSG：4326）一样，将它们转换为网络墨卡托：
gdaltransform -s_srs EPSG:4326 -t_srs EPSG:3857
0 66.3722684317026
0 9979483.26733298 0
45 40.7894557844857
5009377.08569731 4981335.86590183 0结果坐标与idea2的坐标不同：
0 9979483.26733298 5009377.08569731 4981335.86590183 (West North East South)现在，我只需要将坐标写入地图即可：
gdal_translate -of Gtiff -co tfw=yes -a_ullr 0 9979483.26733298 5009377.08569731 4981335.86590183 -a_srs EPSG:3857 4_2.png t3857_through_4055.tif第三个想法似乎给出了最好的结果。但我不确定是否正确。如果想法3是正确的，是否有一个EPSG代码可以一步完成此操作？
第四个想法：EPSG：3857到towgs84 = 0,0,0,0,0,0,0
gdal（显然还有epsg）也这样定义EPSG：3857：
+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 +no_defs而spacespacereference.org像这样：
+proj=merc +lon_0=0 +k=1 +x_0=0 +y_0=0 +a=6378137 +b=6378137 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs如果我使用来自spatialreference.org的定义，那么我一步就得到了正确的坐标（不过，如果它们是“正确的”坐标，我仍然不知道，但是至少它们与想法3相同）：
gdaltransform -s_srs EPSG:4326 -t_srs "+proj=merc +lon_0=0 +k=1 +x_0=0 +y_0=0 +a=6378137 +b=6378137 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs"
0 66.51326044311185
0 9979483.26733298 -17964.0621483233
45 40.97989806962013
5009377.08569731 4981335.86590183 -9152.84527519904为什么EPSG：3857的定义有这样的区别？