簡介面向地圖開發(fā)與GIS應(yīng)用場景的參數(shù)速查文檔聚焦谷歌地圖、搜搜地圖和天地圖三類瓦片地圖服務(wù)的關(guān)鍵配置適合接入在線地圖、制作切片或進(jìn)行坐標(biāo)投影轉(zhuǎn)換的開發(fā)人員參考。文檔以1個docx文件交付壓縮包約15KB體量輕便便于隨項目資料歸檔檢索。已有101人學(xué)習(xí)說明其在瓦片地圖參數(shù)對照中具有一定參考價值。內(nèi)容圍繞切片原點、全圖范圍、地圖投影、軸方向、顯示級別及比例尺集合展開分別梳理WGS84 Web Mercator與China Geodetic Coordinate System 2000等差異并列出0—17級、4—18級、1—18級等范圍。讀者可據(jù)此快速核對參數(shù)口徑為切片生成、API集成、數(shù)據(jù)轉(zhuǎn)換和跨服務(wù)兼容排查提供依據(jù)。1. 三套瓦片參數(shù)擺一起坐標(biāo)系原點差一位小數(shù)就能讓地圖整體偏移上個月幫朋友排查一個離線地圖錯位的問題現(xiàn)象很怪底圖能出來標(biāo)注也能出來但放大到街道級之后路網(wǎng)整體往右下角飄了幾百米。他用的是從三家服務(wù)商各扒了一層的拼接方案圖源混著用自己寫著寫著就串了參數(shù)。最后定位到的原因很簡單——切片原點差了不到一米Y 軸方向還是反的。瓦片地圖參數(shù)這東西看文檔時覺得都是常識真動手拼的時候一個比例尺集合對不上、一個原點正負(fù)號寫反就能讓你在半夜對著屏幕懷疑人生。這篇就把三套典型瓦片服務(wù)的參數(shù)拆開對比切片原點、全圖范圍、地圖投影、顯示級別與比例尺集合講清楚它們?yōu)槭裁床灰粯?、混用時要注意什么、怎么自己算一遍驗證。GIS 開發(fā)和地圖數(shù)據(jù)處理的同學(xué)可以直接拿去對照做切片拼接和坐標(biāo)轉(zhuǎn)換的也能少走幾段彎路。2. 先看四個核心參數(shù)切片原點、全圖范圍、投影、比例尺集合2.1 切片原點為什么是最先要看的東西切片原點決定了瓦片編號的起點也就是整張世界地圖被切格子的時候左上角那個格子從哪個坐標(biāo)開始數(shù)。業(yè)內(nèi)對 Web Mercator 的常規(guī)做法是把原點放在投影坐標(biāo)系的左上角因為屏幕坐標(biāo) Y 軸朝下瓦片行號往下遞增和這個原點配合起來最自然。但注意所謂「左上角」在不同的服務(wù)里并不是同一個數(shù)。投影坐標(biāo)下的理論邊界是 ±20037508.342789244 左右實際實現(xiàn)里各家取的精度不一樣寫出來的值就有末位差異。我在做的模擬項目里同時接了三種圖源一開始直接把原點當(dāng)成常量寫死結(jié)果換源就錯。后來改成按圖源讀配置問題才消失。常見的思路是原點不要靠記憶靠配置配置不要手抄靠驗證。驗證方式很簡單——取一個已知坐標(biāo)點用 0 級瓦片的范圍反算一次看算出來的瓦片號是不是 0。算出來是 0原點就是對的算出來是 1 或者 -1說明原點或者軸方向出了問題。2.2 全圖范圍和 Y 軸方向最容易翻車的一對三套服務(wù)的全圖范圍差異比原點更能說明問題。谷歌地圖的 Y 軸正方向向下全圖范圍在投影坐標(biāo)下是左下角到右上角一整個方形搜搜地圖的 Y 軸正方向向上全圖范圍的寫法就跟著換了一套符號天地圖則干脆不在投影坐標(biāo)里寫范圍直接用經(jīng)緯度 -180 到 180、-90 到 90原點也寫成 (-180, 90)。這三種寫法背后是同一個邏輯原點加上軸方向才能確定瓦片編號的映射關(guān)系。只看范圍不看軸方向等于只看了半張說明書。我一般會這么做——把「原點 軸方向 全圖范圍」當(dāng)成一個三元組記缺一個就不下結(jié)論。血淚經(jīng)驗是只要這三者里有一個是從別的圖源抄來的錯位就是必然的而且往往只在放大到一定級別后才明顯排查時極容易誤判成投影轉(zhuǎn)換寫錯。服務(wù)切片原點X 軸方向Y 軸方向全圖范圍寫法谷歌地圖(-20037508.342789199, 20037508.342789199)向右向下投影坐標(biāo)方形范圍搜搜地圖(-20037508.342789244, 20037508.342789091)向右向上投影坐標(biāo)方形范圍天地圖(-180, 90)向右向下經(jīng)緯度 -180~180、-90~902.3 投影不同參數(shù)就不能互抄谷歌和搜搜都用 WGS84 Web Mercator天地圖用的是 China Geodetic Coordinate System 2000。前兩者是同一套投影參數(shù)差異主要是精度和實現(xiàn)習(xí)慣理論上可以把瓦片編號對得上只是原點末位差一點嚴(yán)謹(jǐn)起來還是要按各自的數(shù)算。天地圖不一樣原點直接落在經(jīng)緯度上全圖范圍也是經(jīng)緯度這意味著它的瓦片編號是在經(jīng)緯度平面上切格子的和 Web Mercator 的切片思路不是一回事。所以「天地圖能不能和另外兩個混著拼」這個問題答案不是一個能不能而是看你在哪一層混。在經(jīng)緯度層面混需要先把 Web Mercator 的瓦片反投影回經(jīng)緯度再按天地圖的規(guī)則重新編號在投影坐標(biāo)層面混就要做一次投影轉(zhuǎn)換。前者精度損失小一些后者在高緯度地區(qū)會累積誤差。我見過的做法是統(tǒng)一在經(jīng)緯度層面做中間層圖源各自負(fù)責(zé)自己那一段拼接層只認(rèn)經(jīng)緯度這樣換源的時候改動面最小。這個思路在模擬項目里驗證過代價是每次渲染多一次轉(zhuǎn)換開銷但在級別不高、瓦片數(shù)量可控的情況下完全能接受。2.4 比例尺集合要整段對不是對首尾比例尺集合是三套參數(shù)里最容易被忽略的部分。很多人只對首尾兩個值覺得中間差一點無所謂實際上瓦片的級別映射就是靠這個集合逐級對應(yīng)的。谷歌地圖的集合從 1.6901635716026553E-9 起到 2.2153311965710323E-4 收搜搜地圖從 2.7042617145642484E-8 起到 4.4306623931420646E-4 收天地圖從 3.3803271432053105E-9 起到 4.4306623931420646E-4 收。盯一眼能看出來搜搜的 4 到 18 級和谷歌的 2 到 16 級在數(shù)值上是重合的天地圖 1 到 18 級的前 18 個值也和谷歌有交集。這不是巧合級別比例尺是按 2 的冪遞推出來的只要起點一致后續(xù)自然對齊。對齊的部分可以互認(rèn)不對齊的部分必須各自算。常見的誤用是拿級別號直接互轉(zhuǎn)比如把谷歌的 5 級當(dāng)成搜搜的 5 級結(jié)果就是差兩級的錯位畫面糊成一團(tuán)。3. 三家參數(shù)逐項對比哪些能互認(rèn)哪些必須各算各的3.1 谷歌與搜搜同一投影下的精度差異這兩個放一起比最有價值因為它們是同一套投影差異全在實現(xiàn)細(xì)節(jié)上。原點的差距在末位X 方向一個是 -20037508.342789199一個是 -20037508.342789244差了大概 4.5e-8 米這個量級在實際渲染里可以忽略但嚴(yán)謹(jǐn)起來不能直接等號。Y 方向更明顯谷歌是 20037508.342789199搜搜是 20037508.342789091而且搜搜的 Y 軸正方向向上等于符號系統(tǒng)整個換了。這帶來的直接后果是行號的遞增方向相反。谷歌的瓦片行號往下遞增搜搜的往上遞增同一個地理位置的瓦片行號大概率不一樣。我一開始就是栽在這里以為投影一樣就能直接換結(jié)果地圖上下顛倒還以為是渲染管線寫反了?；剡^頭看判斷依據(jù)應(yīng)該落在軸方向上而不是投影名稱上。對比項谷歌地圖搜搜地圖能否互認(rèn)投影WGS84 Web MercatorWGS84 Web Mercator可以原點 X-20037508.342789199-20037508.342789244精度差可忽略原點 Y20037508.34278919920037508.342789091數(shù)值接近但軸方向不同Y 軸方向向下向上不可互認(rèn)級別范圍0-174-18部分級別數(shù)值重合級別范圍那一欄值得多說一句。谷歌 0-17 級搜搜 4-18 級重合區(qū)間的比例尺數(shù)值是一致的。這意味著如果你在做級別映射正確的換算是按比例尺值找對應(yīng)級別而不是按級別號加減。寫代碼的時候可以建一張「級別-比例尺」的字典兩邊都按值查就不用管級別號差幾級了。3.2 天地圖換了一套坐標(biāo)系就別硬拼天地圖的參數(shù)看著簡單原點 (-180, 90)范圍 -180 到 180、-90 到 90但簡單恰恰是它難拼的原因——它在經(jīng)緯度平面上切和投影坐標(biāo)平面不是同一個空間。在模擬項目里我一開始想省事直接拿經(jīng)緯度當(dāng)投影坐標(biāo)去做像素?fù)Q算結(jié)果比例完全不對一個 0 級瓦片鋪不滿屏幕縮到小比例尺就成大花臉。正確的做法是先明確你在哪一層做拼接。如果是渲染層把另外兩家的瓦片反投影回經(jīng)緯度和天地圖對齊如果是數(shù)據(jù)層統(tǒng)一轉(zhuǎn)成同一種投影再切。前者改動小、精度夠用后者一勞永逸但工程量大。我傾向前者因為瓦片本身是很難回頭重切的加一層轉(zhuǎn)換比重新造一套切片便宜得多。提示跨坐標(biāo)系拼接時先拿一個已知地標(biāo)做驗證點算出三個圖源各自對應(yīng)的瓦片行列號比對是否落在同一地理區(qū)域再決定在哪一層做轉(zhuǎn)換。3.3 用一段腳本把參數(shù)算一遍別只看文檔參數(shù)對不對算一遍最踏實。下面這段是我常用的驗證腳本思路是拿參數(shù)反算瓦片行列號再用同一坐標(biāo)去比對三套服務(wù)的結(jié)果。腳本里所有數(shù)值都來自前面列的參數(shù)沒有額外編造。import math # 三套服務(wù)的參數(shù)原點與軸方向決定編號映射 SERVICES { google: { origin: (-20037508.342789199, 20037508.342789199), y_down: True, max_level: 17, }, soso: { origin: (-20037508.342789244, 20037508.342789091), y_down: False, # Y 軸向上行號遞增方向相反 max_level: 18, }, tianditu: { origin: (-180.0, 90.0), # 經(jīng)緯度平面不是投影坐標(biāo) y_down: True, max_level: 18, is_lonlat: True, }, } def tile_index(x, y, level, svc): cfg SERVICES[svc] ox, oy cfg[origin] # 每級把整幅圖分成 2^level 個格子先求出單格跨度 span (360.0 if cfg.get(is_lonlat) else 2 * 20037508.342789244) / (2 ** level) col int((x - ox) / span) dy (oy - y) if cfg[y_down] else (y - oy) row int(dy / span) return col, row # 用同一組坐標(biāo)交叉驗證若三套結(jié)果落在相近格子內(nèi)說明參數(shù)沒串 print(tile_index(116.39, 39.91, 10, tianditu)) print(tile_index(116.39, 39.91, 10, google))這段代碼有幾個地方需要說明。span 是按全圖范圍除以 2 的級別次冪算的Web Mercator 那邊用的是 ±20037508.342789244 的整幅寬度天地圖用的是 360 度經(jīng)度跨度兩者單位不同所以用 is_lonlat 區(qū)分。dy 那行是核心y_down 為真時用原點減坐標(biāo)為假時反過來這樣搜搜的向上軸也能算對行列號。參數(shù)改起來很簡單換服務(wù)就換 key級別按需調(diào)但注意天地圖傳的是經(jīng)緯度另外兩家要先轉(zhuǎn)投影坐標(biāo)再傳否則算出來的格子沒有意義。跑完之后如果三套結(jié)果對應(yīng)的地理區(qū)域一致說明參數(shù)關(guān)系理解對了如果不一致先看軸方向再看單位最后才懷疑精度。這個順序能省掉八成排查時間。4. 避坑與排查拼接瓦片時最容易踩的五個坑4.1 坑一把 Y 軸方向當(dāng)成全局常量現(xiàn)象是換圖源后地圖整體上下顛倒或者行號對不上、瓦片錯位一整行。原因是代碼里把 Y 軸向下寫死而搜搜地圖是向上的符號一錯整條映射就反了。解決方式是把軸方向做成配置項和原點綁在一起凡是算行號的地方都讀這個配置不在任何一處硬編碼正負(fù)。我后來的習(xí)慣是參數(shù)對象里必須有 y_down 字段缺了就直接報錯寧可啟動失敗也不帶著錯跑。4.2 坑二級別號直接互轉(zhuǎn)現(xiàn)象是切到某個級別后畫面模糊或者明明放大了一級看起來沒變化。原因是按級別號做加減而三家級別范圍的起點不同谷歌 0 級、搜搜 4 級、天地圖 1 級同樣的級別號對應(yīng)的比例尺根本不是一回事。解決方式是建立「比例尺-級別」雙向表按比例尺值查級別代碼里禁止出現(xiàn)level 2這類硬編碼偏移。4.3 坑三拿天地圖的經(jīng)緯度當(dāng)投影坐標(biāo)用現(xiàn)象是小比例尺下瓦片鋪不滿或者嚴(yán)重拉伸放大后稍微正常一點。原因是天地圖原點和范圍都是經(jīng)緯度直接代入 Web Mercator 的公式單位對不上算出來的跨度差了十幾萬倍。解決方式是先判斷當(dāng)前圖源屬于哪套坐標(biāo)平面經(jīng)緯度平面走一套公式投影平面走另一套中間需要時再做投影轉(zhuǎn)換。4.4 坑四比例尺集合只看首尾現(xiàn)象是部分級別正常、部分級別偏移且偏移量隨級別變化。原因是對比例尺集合做了首尾對齊中間值其實不完全一致級別映射在中間段就開始漂。解決方式是整段比或者干脆按 2 的冪遞推自己生成一份和服務(wù)商給的對一遍對不上的段落單獨處理。4.5 坑五原點精度差異被當(dāng)成錯誤現(xiàn)象是發(fā)現(xiàn)末位差了幾位小數(shù)以為參數(shù)錯了回頭去改配置結(jié)果越改越亂。原因是各家實現(xiàn)精度本來就不同末位差異在渲染層面可以忽略。解決方式是定一個容差比如相對誤差小于千分之一就當(dāng)相同處理把精力放在軸方向和坐標(biāo)系上別在末位上浪費夜里的時間。注意排查順序建議固定為軸方向、坐標(biāo)平面、級別映射、精度容差從影響大的往影響小的查不要一上來就懷疑浮點誤差。5. 落到一份參數(shù)配置表怎么寫才不怕?lián)Q源5.1 把參數(shù)寫成配置而不是散落的常量我踩完前面那些坑之后做法是把三套參數(shù)整理成一份配置每個圖源一個對象字段固定原點、Y 軸方向、坐標(biāo)平面類型、級別范圍、比例尺集合。加載瓦片時只認(rèn)這個對象任何計算都從這里取數(shù)。這樣做的好處是換源只是換一個 key代碼路徑不變出問題也只可能出在配置本身排查面小得多。配置里有個細(xì)節(jié)值得強(qiáng)調(diào)比例尺集合要原樣保留科學(xué)計數(shù)法的精度別在序列化的時候被截斷。我見過一次因為 JSON 解析丟精度導(dǎo)致中間幾級映射偏了半格畫面看著不糊但標(biāo)注偏了幾十米查了很久才懷疑到精度上。穩(wěn)妥的做法是集合按字符串存用的時候再轉(zhuǎn)浮點。5.2 驗證環(huán)節(jié)不能省配置寫完不等于對了要有一個驗證入口。我的做法是挑若干個已知地標(biāo)分別算出三個圖源對應(yīng)的瓦片行列號人工比對是否落在同一區(qū)域。這個環(huán)節(jié)一次也就十分鐘但能擋掉絕大部分配置錯誤。模擬項目上線前跑了這一遍當(dāng)場發(fā)現(xiàn)天地圖那段單位沒轉(zhuǎn)省了上線后的一次回滾。5.3 換源時的檢查清單換源之前先問四個問題投影是不是同一套、原點是不是同一套符號系統(tǒng)、級別范圍有沒有交集、比例尺集合能不能逐級對上。四個都能答上來再動手改答不上來就先補參數(shù)。這個清單我用到現(xiàn)在還沒失效過后悔藥能少吃不少。檢查項判斷依據(jù)不通過的后果投影一致投影名稱與坐標(biāo)單位比例失真、拉伸軸方向一致行號遞增方向上下顛倒、錯行級別有交集級別范圍重疊區(qū)間部分級別缺圖比例尺可對逐級數(shù)值比對中間級別偏移5.4 一個具體技巧用 0 級瓦片反推原點最后留一個我自己常用的技巧。不管參數(shù)從哪來先算 0 級瓦片的行列號整幅世界地圖在 0 級只有一張瓦片行列號必須是 0。如果算出來是別的數(shù)說明原點或者軸方向有問題如果算出來是 0 但地圖還是偏問題就在級別映射或者投影轉(zhuǎn)換上不在原點。這個檢查只用一行計算卻能第一時間把問題范圍砍掉一半。從那以后我每次接新圖源都強(qiáng)制先用 0 級瓦片驗一遍原點再往下做別的希望幫到你。本文還有配套的精品資源點擊獲取