gdal을 사용하여 웹 메르카토르 타일을 올바르게 지리 참조하는 방법은 무엇입니까?

예를 들어 다음 타일 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 또는 다른 지리 참조 형식을 생성하는 방법) :

• 비트 맵을 늘일 필요는 없습니다 (= Geotiff의 픽셀은 원래 비트 맵의 ​​픽셀과 정확히 동일합니다)
• 결과 이미지가 GIS 뷰어 / 편집기의 올바른 위치에 열립니다 (예 : TatukGIS Free Viewer )?

(질문을 명확하게하고 결론을 포함시키기 위해 2011 년 9 월 19 일에 편집 함)

내 결론 :

나는 먼저 세 번째 아이디어 (아래 참조)가 올바른 아이디어라고 생각했습니다. GIS 뷰어에서 geotiff를 열고 표시된 좌표를 예상 한 것과 비교했습니다. 두 번째 아이디어에서 나온 지오텍은 북쪽으로 2 픽셀 이동 한 것으로 보입니다. 그렇기 때문에 아이디어 3 (또는 4)을 올바른 아이디어로 생각했습니다.
그러나 훨씬 높은 줌 레벨에서 타일을 사용하면 아이디어 3의 지오 틱이 결정적으로 남쪽으로 이동합니다. 확대 / 축소 수준 3의 타일에서 좌표를 비교하는 것은 어리석은 일이었습니다. 그러한 확대 / 축소 수준의 국가 경계는 크게 단순화되어 비교 결과가 좋지 않습니다.

Dan S.가 옳았습니다. 타일 이미지는 이미 EPSG : 3857입니다. 두 번째 아이디어는 올바른 아이디어입니다 (높은 줌 레벨에서도 좋은 결과를 제공합니다)

첫 번째 아이디어 : EPSG : 4326
WGS84 좌표의 EPSG 코드는 EPSG : 4326 입니다. 따라서 gdal_translate을 사용하여 WGS84 좌표를 사용하여 타일을 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 좌표를 사용할 수 있도록 이미지를 streched해야합니다.

두 번째 아이디어 : 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 좌표를 사용하지만 구형 좌표 인 것처럼 생각합니다. 측지와 지구 중심 위도의 차이로 인해 (위도 에 대한 위키 백과 참조 ) 위도 값은 타원체 또는 구에서 동일하지 않습니다. 그 발견 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

spacereference.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

patialreference.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의 정의에 왜 그러한 차이가 있습니까?

타일 ​​이미지는 이미 EPSG : 3857입니다. 왜 그것을 참조 할 월드 파일을 만들지 않습니까?

http://en.wikipedia.org/wiki/World_file

확대 / 축소 1에서 북미를 덮는 타일의 경우 다음과 같은 월드 파일 내용을보고 있습니다.

78271.517
0
0
-78271.517
-19998372.6
19998372.6

그 번호는 어디에서 왔습니까?

• 라인 1 : 월드 좌표의 이미지 픽셀 너비 = 20037508.342789244 미터 / 256 픽셀.
• 라인 2 및 3 : 회전이므로 해당 없음.
• 4 행 : 월드 좌표에서 이미지 픽셀의 높이. 이미지 파일에서 y를 증가 시키면 'down'에 해당하고 좌표계에서는 y를 증가 시키면 'up'에 해당하므로 1 행과 동일하지만 음수입니다.
• 5 행 : 왼쪽 상단 픽셀 중심의 월드 좌표로 X 좌표. 타일에서 알라 카르 트 링크와 함께 픽셀의 1/2을 더한 가운데 -20037508.342789244입니다.
• 6 행 : 왼쪽, 왼쪽 상단의 Y 좌표 만.

GDAL은 월드 파일 (PNG의 경우 .pgw)을 가져와야합니다. 명령 행에서 여전히 EPSG : 3857을 알려야합니다.

(참고 :이 시간을 테스트 할 시간이 없었으므로 커프에서 벗어났습니다 ...하지만 첫 번째 시도에서 올바르게 수정하십시오!;)

웹에서 사용되는 전역 타일 생성에 필요한 기능. 다음에 대한 좌표 변환을 구현하는 클래스를 포함합니다.

• Google Maps, Yahoo Maps, Microsoft Bing Maps 호환 타일 용 GlobalMercator ( EPSG : 900913 = EPSG : 3785 기반 )

• OpenLayers 기본 맵 및 Google 어스 호환 타일 용 GlobalGeodetic (EPSG : 4326 기반)

http://svn.osgeo.org/gdal/sandbox/klokan/gdal2tiles.py

네 번째 아이디어의 두 번째 질문에 대해 : gdal 정의와 patialreference.org에서 EPSG : 3857의 정의에 왜 그러한 차이가 있습니까 ?

주요 차이점은 gdal은 "+ nadgrids = @ null"및 공간 참조 "+ towgs84 = 0,0,0,0,0,0,0"을 사용한다는 것입니다. 문서 또는 PROJ.4 형식 에 따르면 두 매개 변수 모두 데이텀 변환에 사용됩니다. Proj4 목록 서버에서 Mikael Rittri 의 흥미로운 의견을 찾았습니다 .

"The +to definition you suggest is not correct for WGS84 Web Mercator, though.
This is because the datum shift you use, 

   +towgs84=0,0,0,0,0,0,0

is not the same as unmodified lat/long, or "without any datum shift" as you say.
It means "no datum shift" only if the +from and +to definitions use the same ellipsoid,
and in your case the +from definition uses the WGS84 ellipsoid, while the +to definition
uses a sphere instead.  

So, you have to use a trick: use 

   +nadgrids=@null 

instead."

"+ towgs84 = 0,0,0,0,0,0,0"의 사용은 옳거나 적어도 특정 조건 하에서 만 보이지 않는 것 같습니다.