去年有個(gè)項(xiàng)目讓我頭疼了整整一周?？蛻舻膬?nèi)網(wǎng)系統(tǒng)里要嵌入一張城市地圖頁面早就做好地圖容器也畫出來了但打開之后整張底圖全是灰的連一條道路都看不見。我當(dāng)時(shí)第一反應(yīng)是JS代碼報(bào)錯(cuò)查了半小時(shí)也沒查出問題。后來打開開發(fā)者工具才發(fā)現(xiàn)瀏覽器一直在向高德的瓦片服務(wù)器發(fā)請(qǐng)求全部超時(shí)失敗。原因很直白內(nèi)網(wǎng)訪問不了外網(wǎng)而地圖底圖本身就是一張張動(dòng)態(tài)請(qǐng)求下來的瓦片圖片。這次我不打算只貼一段下載代碼而是把“高德地圖瓦片”從URL規(guī)則、下載器編寫、內(nèi)網(wǎng)服務(wù)搭建到前端接入這條鏈路完整拆開講。讀完之后你至少能解決三件事搞懂高德瓦片URL的規(guī)律寫一個(gè)能斷點(diǎn)續(xù)傳的瓦片下載器把瓦片用Nginx托管起來并讓Leaflet或高德JS API正常加載。適合正在做內(nèi)網(wǎng)GIS、數(shù)據(jù)大屏、離線地圖項(xiàng)目的開發(fā)者參考。1. 為什么內(nèi)網(wǎng)里地圖總是一片空白瓦片加載機(jī)制與隔離網(wǎng)絡(luò)困境1.1 地圖瓦片到底是什么地圖上那套連續(xù)光滑的畫面其實(shí)被切成了固定大小的小方塊每個(gè)小方塊就是一張瓦片最常見的規(guī)格是256x256像素高清屏有512x512。所有瓦片按縮放級(jí)別組織級(jí)別越高地圖范圍越精細(xì)瓦片數(shù)量越多同一個(gè)級(jí)別下瓦片按x列號(hào)和y行號(hào)排列從左上角開始計(jì)數(shù)。我經(jīng)常用一個(gè)拼圖比喻來解釋縮放級(jí)別是拼圖的精細(xì)度x和y是拼圖塊的行列坐標(biāo)z是整套拼圖的頁碼。瀏覽器里的高德地圖本質(zhì)上就是根據(jù)當(dāng)前視野范圍、中心點(diǎn)和縮放級(jí)別動(dòng)態(tài)計(jì)算需要哪幾頁拼圖的哪些塊然后向服務(wù)器把對(duì)應(yīng)圖片一張張取回來拼到屏幕對(duì)應(yīng)的位置上。沒有這些瓦片圖片底圖就什么都畫不出來。1.2 高德JS API加載底圖的完整鏈路高德JS API在頁面上初始化Map對(duì)象之后會(huì)自動(dòng)維護(hù)視圖狀態(tài)包括中心點(diǎn)經(jīng)緯度、縮放級(jí)別、DOM容器尺寸等。只要視圖有變化不管是拖動(dòng)、縮放還是窗口尺寸變化它都會(huì)基于瓦片編號(hào)算法算出當(dāng)前視野覆蓋的瓦片集合生成一組圖片URL把圖片元素插入到地圖容器里。這些URL指向的是高德的瓦片服務(wù)地址結(jié)構(gòu)大致如下https://webrd0{1-4}.is.autonavi.com/appmaptile?x{x}y{y}z{z}langzh_cnsize1scale1style8瀏覽器向這個(gè)地址發(fā)起HTTP請(qǐng)求高德服務(wù)器返回對(duì)應(yīng)的PNG圖片。整個(gè)過程對(duì)前端使用者是透明的你只看到地圖“畫”出來了背后其實(shí)是幾十張圖片在快速加載和拼接。只要中間任何一條鏈路走不通底圖就會(huì)空白。內(nèi)網(wǎng)環(huán)境最典型的問題就是域名解析不到外網(wǎng)或者外網(wǎng)請(qǐng)求直接被防火墻攔截。1.3 內(nèi)網(wǎng)環(huán)境下的三種典型需求我實(shí)際接觸過的內(nèi)網(wǎng)地圖需求大概分三類出發(fā)點(diǎn)各不相同但最終都落到同一個(gè)技術(shù)動(dòng)作上業(yè)務(wù)系統(tǒng)地圖展示內(nèi)部管理平臺(tái)需要在地圖上疊加資產(chǎn)點(diǎn)位、人員軌跡、區(qū)域邊界底圖必須放在內(nèi)網(wǎng)這是最基礎(chǔ)的要求。數(shù)據(jù)可視化大屏大屏項(xiàng)目普遍追求高德風(fēng)格的街道圖或衛(wèi)星圖效果但又不能在演示現(xiàn)場(chǎng)賭外網(wǎng)帶寬瓦片本地化成了唯一靠譜方案。應(yīng)急離線地圖一些現(xiàn)場(chǎng)環(huán)境網(wǎng)絡(luò)狀態(tài)不穩(wěn)定提前把目標(biāo)區(qū)域瓦片下載到本地現(xiàn)場(chǎng)直接用靜態(tài)服務(wù)撐住整個(gè)演示方便又省心。這三類需求落到技術(shù)動(dòng)作上完全一致先把瓦片下載到內(nèi)網(wǎng)再讓前端從內(nèi)網(wǎng)加載。下面我從瓦片URL規(guī)則開始拆解。2. 拆解高德瓦片URL規(guī)律z/x/y與坐標(biāo)系里藏著的門道2.1 從瀏覽器開發(fā)者工具抓一個(gè)瓦片請(qǐng)求寫下載器之前先得把瓦片URL的規(guī)律摸清楚。方法很簡(jiǎn)單打開一個(gè)使用高德地圖的網(wǎng)頁按F12切到Network面板過濾Image類型請(qǐng)求拖動(dòng)一下地圖就能看到瓦片請(qǐng)求像瀑布一樣刷下來。一個(gè)典型的高德街道圖瓦片請(qǐng)求是這樣的https://webrd01.is.autonavi.com/appmaptile?langzh_cnsize1scale1style8x227y95z8其中webrd01是瓦片服務(wù)器編號(hào)高德做了負(fù)載均衡webrd02、webrd03、webrd04也能取到同樣的瓦片。z是縮放級(jí)別x和y是瓦片行列號(hào)style8表示街道圖scale1是普通分辨率返回256x256scale2返回512x512也就是高清瓦片。把這些參數(shù)拆清楚之后下載器的URL模板就可以直接構(gòu)造了。2.2 經(jīng)緯度與瓦片行列號(hào)的換算公式瓦片行列號(hào)不是隨機(jī)生成的它基于Web Mercator投影EPSG:3857做了全球劃分。把世界地圖看成一個(gè)矩形平面最左上角是(0,0)向右x增大向下y增大。在縮放級(jí)別z下全世界橫向和縱向都分成2的z次方份所以第z級(jí)總共有2^z乘以2^z張瓦片。已知經(jīng)緯度轉(zhuǎn)瓦片行列號(hào)的公式用Python可以寫成這樣import math def lonlat_to_tile(lon, lat, z): n 2 ** z x int((lon 180.0) / 360.0 * n) rad math.radians(lat) y int((1.0 - math.asinh(math.tan(rad)) / math.pi) / 2.0 * n) return x, y這里asinh(tan(rad))和常用的ln(tan(rad) 1/cos(rad))是等價(jià)的只是寫起來更簡(jiǎn)潔。Web Mercator在縱坐標(biāo)上用了非線性變換所以緯度越高相鄰?fù)咂淼膶?shí)際面積越小這也解釋了為什么高緯度地區(qū)在地圖上看起來被明顯放大了。2.3 GCJ-02坐標(biāo)系差異為什么用WGS-84坐標(biāo)算出來的瓦片會(huì)偏移高德瓦片最容易踩的隱性坑就是坐標(biāo)系。高德的坐標(biāo)體系是GCJ-02俗稱火星坐標(biāo)而GPS設(shè)備、第三方矢量數(shù)據(jù)常用的卻是WGS-84。瓦片行列號(hào)本身基于投影平面計(jì)算但在高德體系內(nèi)這個(gè)平面坐標(biāo)對(duì)應(yīng)的經(jīng)緯度基準(zhǔn)是GCJ-02不是WGS-84。如果你拿著一批GPS采集的WGS-84經(jīng)緯度坐標(biāo)直接套前面的公式算x/y去請(qǐng)求高德瓦片邊界框整體會(huì)偏移幾百米甚至上千米。結(jié)果就是你想下載A區(qū)域的瓦片實(shí)際拿到的卻是A區(qū)域偏移后的范圍。解決辦法是先做WGS-84到GCJ-02的坐標(biāo)轉(zhuǎn)換再參與行列號(hào)計(jì)算。如果項(xiàng)目里的坐標(biāo)本來就來自高德JS API或者高德地圖拾取器那它們已經(jīng)在GCJ-02體系內(nèi)直接用即可。坐標(biāo)轉(zhuǎn)換不建議自己造輪子用現(xiàn)成的coordtransform庫或者找一份成熟的七參數(shù)轉(zhuǎn)換實(shí)現(xiàn)都可以。這里不展開但它確實(shí)是整個(gè)鏈路里最容易出問題的一環(huán)后面第5章我會(huì)再提排查思路。2.4 瓦片規(guī)格普通屏與高清屏的差異高德瓦片接口的scale參數(shù)直接影響顯示效果和存儲(chǔ)成本。scale1返回256x256單張大約10-20KBscale2返回512x512單張大約30-60KB。同樣的范圍高清瓦片占用的存儲(chǔ)空間通常翻三到四倍。做普通PC端Web系統(tǒng)scale1完全夠用。做數(shù)字大屏或者需要截圖輸出的場(chǎng)景我建議直接用scale2否則畫面放大后全是鋸齒。關(guān)鍵點(diǎn)是下載時(shí)用了什么scale前端URL模板就要保持一致混用會(huì)導(dǎo)致瓦片物理尺寸不一致拼接出來非常難看。這個(gè)我在第5章的踩坑記錄里還會(huì)再講。3. 寫一個(gè)瓦片下載器從邊界框計(jì)算到并發(fā)斷點(diǎn)續(xù)傳3.1 規(guī)劃下載范圍用經(jīng)緯度邊界框確定瓦片數(shù)量下載瓦片的第一步不是寫循環(huán)而是先明確下載范圍。范圍一般用經(jīng)緯度矩形邊界框描述也就是最小經(jīng)度、最小緯度、最大經(jīng)度、最大緯度?？s放級(jí)別范圍取決于業(yè)務(wù)城區(qū)大屏項(xiàng)目通常15到17級(jí)就夠18級(jí)以上瓦片數(shù)量會(huì)暴漲下載時(shí)間和磁盤占用都不劃算。我習(xí)慣先估算瓦片數(shù)量再動(dòng)手。以北京城區(qū)大約1.5度經(jīng)度跨度、1.2度緯度跨度為例在17級(jí)下的數(shù)量大概是這樣的縮放級(jí)別2^z示例城市橫向瓦片數(shù)示例城市縱向瓦片數(shù)總瓦片數(shù)約15327681372182.9萬166553627343711.9萬1713107254687447.7萬1826214410921748190.9萬47萬張256x256的PNG按平均15KB算大約7GB這個(gè)量級(jí)在單機(jī)磁盤上可以接受。但如果盲目把18級(jí)也加進(jìn)來量級(jí)立刻變成一百多萬張存儲(chǔ)和時(shí)間成本都高一個(gè)量級(jí)。先算賬再動(dòng)手能省掉很多溝通成本。3.2 用邊界框換算出瓦片行列號(hào)集合有了邊界框就可以按級(jí)別生成行列號(hào)列表。這里有個(gè)新手容易搞反的地方Web Mercator中緯度越大的地方y(tǒng)值越小所以北邊界的y數(shù)比南邊界小。生成列表時(shí)需要對(duì)y方向取最小到最大不然范圍會(huì)亂。def tile_range(min_lon, min_lat, max_lon, max_lat, z): x0, y0 lonlat_to_tile(min_lon, max_lat, z) # 左上角 x1, y1 lonlat_to_tile(max_lon, min_lat, z) # 右下角 for x in range(x0, x1 1): for y in range(min(y0, y1), max(y0, y1) 1): yield x, y這個(gè)生成器給出某一級(jí)別下的行列號(hào)集合。再套一層級(jí)別循環(huán)就能得到完整任務(wù)列表。任務(wù)列表可以提前序列化到本地留檔方便后面斷點(diǎn)續(xù)傳時(shí)做對(duì)比也方便你分級(jí)別分批次執(zhí)行下載。3.3 編寫下載函數(shù)單線程先跑通把坑都踩清楚我習(xí)慣先用單線程把一條鏈路跑通。這個(gè)版本不用考慮效率和優(yōu)雅重點(diǎn)是確定目錄結(jié)構(gòu)、請(qǐng)求頭、文件命名這些基礎(chǔ)約定。import os import requests def download_tile(z, x, y, url_template, save_root): save_dir os.path.join(save_root, str(z), str(x)) os.makedirs(save_dir, exist_okTrue) save_path os.path.join(save_dir, f{y}.png) url url_template.format(zz, xx, yy) resp requests.get(url, timeout10, headers{User-Agent: Mozilla/5.0}) if resp.status_code 200: with open(save_path, wb) as f: f.write(resp.content)目錄結(jié)構(gòu)是save_root/{z}/{x}/{y}.png這個(gè)結(jié)構(gòu)正好對(duì)應(yīng)Nginx靜態(tài)服務(wù)的URL路徑前端模板直接拼{z}/{x}/{y}.png就能用。單線程跑通的好處是能提前發(fā)現(xiàn)偶發(fā)超時(shí)、403、空文件這類問題這些問題在并發(fā)場(chǎng)景里會(huì)被無限放大后面排查起來更痛苦。3.4 并發(fā)下載與失敗重試單線程跑太慢幾萬張瓦片能跑到地老天荒。我一般用ThreadPoolExecutor開8個(gè)線程再配合重試機(jī)制和403/429退避邏輯。高德瓦片服務(wù)器對(duì)單IP的請(qǐng)求頻率有限制8個(gè)線程實(shí)測(cè)比較安全再往上就容易觸發(fā)風(fēng)控。import time import requests from concurrent.futures import ThreadPoolExecutor, as_completed def download_tile_safe(z, x, y, url_template, save_root, retries3): save_dir os.path.join(save_root, str(z), str(x)) os.makedirs(save_dir, exist_okTrue) save_path os.path.join(save_dir, f{y}.png) if os.path.exists(save_path) and os.path.getsize(save_path) 0: return True url url_template.format(zz, xx, yy) for attempt in range(retries): try: resp requests.get(url, timeout10, headers{ User-Agent: Mozilla/5.0, Referer: https://www.amap.com/ }) if resp.status_code 200: with open(save_path, wb) as f: f.write(resp.content) return True elif resp.status_code in (403, 429): time.sleep(2 * (attempt 1)) else: time.sleep(0.5) except Exception: time.sleep(1) return False def run_download(tasks, url_template, save_root, workers8): with ThreadPoolExecutor(max_workersworkers) as pool: futures [pool.submit(download_tile_safe, z, x, y, url_template, save_root) for z, x, y in tasks] for future in as_completed(futures): future.result()有個(gè)細(xì)節(jié)務(wù)必注意Referer頭一定要帶。瓦片服務(wù)器會(huì)校驗(yàn)請(qǐng)求來源沒有Referer的請(qǐng)求很容易直接403。退避間隔從2秒開始成倍增長如果重試三次都失敗就把這條任務(wù)記到日志文件里最后統(tǒng)一補(bǔ)下。3.5 斷點(diǎn)續(xù)傳中斷了不用從頭再來幾十萬張瓦片的下載過程中網(wǎng)絡(luò)抖動(dòng)、服務(wù)器斷開都可能導(dǎo)致任務(wù)中斷。斷點(diǎn)續(xù)傳的實(shí)現(xiàn)非常簡(jiǎn)單下載前判斷目標(biāo)文件是否存在存在且大小大于0就直接跳過。上面代碼里第一段判斷就是在做這件事。這個(gè)設(shè)計(jì)帶來的好處是任務(wù)中斷后重新跑一遍腳本已完成的瓦片全部跳過只補(bǔ)剩余部分。我還會(huì)把失敗任務(wù)單獨(dú)記錄全部跑完后統(tǒng)一用同樣的腳本重跑一次基本能把失敗率壓到極低。實(shí)測(cè)下來50萬張瓦片的一次性下載成功率大概在99.5%左右剩下0.5%靠續(xù)傳補(bǔ)上整個(gè)流程很可靠。4. 內(nèi)網(wǎng)瓦片服務(wù)搭建Nginx托管與前端接入4.1 目錄結(jié)構(gòu)讓文件路徑與URL一一對(duì)應(yīng)下載完的瓦片目錄天然就是靜態(tài)文件結(jié)構(gòu)/data/map_tiles/ ├── 8/ │ ├── 226/ │ │ ├── 94.png │ │ └── 95.png │ └── 227/ │ ├── 94.png │ └── 95.png ├── 9/ │ └── ... └── 17/ └── ...HTTP請(qǐng)求/tiles/8/227/95.png可以直接映射到/data/map_tiles/8/227/95.png。只要Nginx配置里把URL前綴和磁盤路徑對(duì)應(yīng)好不需要任何路由改寫前端模板地址就能直接命中物理文件。這個(gè)目錄結(jié)構(gòu)在下載器里就定好了所以下載和托管之間不會(huì)出現(xiàn)路徑斷層的麻煩。4.2 Nginx靜態(tài)托管配置我習(xí)慣單獨(dú)開一個(gè)server塊專門服務(wù)瓦片不跟業(yè)務(wù)接口混在一起避免日志刷屏和路徑?jīng)_突。server { listen 8080; server_name _; location /tiles/ { alias /data/map_tiles/; autoindex off; expires 30d; add_header Cache-Control public, max-age2592000; try_files $uri 404; } }這里要特別注意alias和root的區(qū)別用了alias /data/map_tiles/URL里的/tiles/前綴會(huì)被去掉剩下的路徑直接對(duì)應(yīng)到/data/map_tiles/下。如果誤寫成root /data/map_tiles/Nginx會(huì)去找/data/map_tiles/tiles/8/227/95.png路徑多了一層tiles立刻404。expires 30d讓瀏覽器把瓦片緩存一個(gè)月內(nèi)網(wǎng)環(huán)境下第二次拖動(dòng)地圖會(huì)特別流暢。4.3 Leaflet接入本地瓦片內(nèi)網(wǎng)項(xiàng)目如果不需要高德JS API的復(fù)雜交互能力用Leaflet加載本地瓦片是最省事的路線。L.tileLayer原生支持URL模板{z}、{x}、{y}三個(gè)變量會(huì)自動(dòng)替換成請(qǐng)求時(shí)的行列號(hào)。var map L.map(map, { center: [39.909, 116.397], zoom: 15, minZoom: 8, maxZoom: 17 }); L.tileLayer(http://192.168.1.100:8080/tiles/{z}/{x}/{y}.png, { maxZoom: 17, minZoom: 8, attribution: Map data ? AutoNavi }).addTo(map);這里有個(gè)坐標(biāo)基準(zhǔn)問題高德瓦片是GCJ-02體系Leaflet本身并不關(guān)心坐標(biāo)系它只是把瓦片按位置貼到地圖上。中心點(diǎn)必須用GCJ-02坐標(biāo)才能和瓦片對(duì)齊如果直接用GPS采集的WGS-84坐標(biāo)地圖中心位置會(huì)出現(xiàn)偏移。在這個(gè)底圖上疊加WGS-84的GPS軌跡或POI數(shù)據(jù)同樣要先把數(shù)據(jù)坐標(biāo)轉(zhuǎn)成GCJ-02再疊加否則會(huì)整面偏移。4.4 高德JS API的內(nèi)網(wǎng)加載策略有些項(xiàng)目必須保留高德JS API的交互體驗(yàn)比如縮放控件、標(biāo)記動(dòng)畫、軌跡播放能力。這種情況下可以把高德JS API的JavaScript文件下載到內(nèi)網(wǎng)用內(nèi)網(wǎng)地址引用再通過自定義瓦片圖層把底圖URL指到內(nèi)網(wǎng)。高德JS API支持自定義AMap.TileLayer核心是重寫getTileUrl方法var localLayer new AMap.TileLayer({ getTileUrl: function(x, y, z) { return http://192.168.1.100:8080/tiles/ z / x / y .png; }, zIndex: 100 }); var map new AMap.Map(container, { center: [116.397, 39.909], zoom: 15, layers: [localLayer] });這樣頁面看起來還是高德地圖底圖卻完全走內(nèi)網(wǎng)。需要提醒的是高德JS API內(nèi)網(wǎng)化要注意安全密鑰和域名白名單的配置這塊取決于項(xiàng)目申請(qǐng)API Key時(shí)的授權(quán)范圍。另外JS API里依賴在線服務(wù)的功能比如實(shí)時(shí)路況、搜索建議、路線規(guī)劃在內(nèi)網(wǎng)環(huán)境依然不可用需要用自建服務(wù)或者離線算法兜底。5. 實(shí)際項(xiàng)目中的坑偏移、白邊、限流與范圍規(guī)劃5.1 瓦片對(duì)不上號(hào)坐標(biāo)偏移的排查思路瓦片下載完成后最常遇到的癥狀是底圖出來了但業(yè)務(wù)數(shù)據(jù)整體偏了幾百米。遇到這種情況先別急著調(diào)前端按順序排查三件事第一確認(rèn)業(yè)務(wù)數(shù)據(jù)到底是什么坐標(biāo)系第二確認(rèn)瓦片行列號(hào)是基于什么坐標(biāo)系計(jì)算的第三確認(rèn)前端中心點(diǎn)和疊加數(shù)據(jù)用的坐標(biāo)基準(zhǔn)是否一致。高德體系內(nèi)默認(rèn)是GCJ-02GPS手持機(jī)、第三方矢量數(shù)據(jù)默認(rèn)是WGS-84。兩者在經(jīng)緯度數(shù)值上相差一點(diǎn)投影到地圖上就是幾百米的平移。我的解決習(xí)慣是項(xiàng)目一開始就定好規(guī)范所有入庫坐標(biāo)統(tǒng)一轉(zhuǎn)成GCJ-02所有瓦片行列號(hào)用GCJ-02計(jì)算前端中心點(diǎn)直接用GCJ-02。統(tǒng)一基準(zhǔn)之后這個(gè)坑基本就不會(huì)再出現(xiàn)了。5.2 瓦片拼接處出現(xiàn)白線內(nèi)網(wǎng)加載本地瓦片后偶爾會(huì)在瓦片拼接縫看到一條細(xì)細(xì)的白線尤其在地圖縮放動(dòng)畫過程中最明顯。這不是瓦片沒下全而是瀏覽器在縮放或位移時(shí)對(duì)瓦片做了采樣相鄰?fù)咂g露出背景色看起來就是一條半透明的縫隙。處理辦法有幾個(gè)層次最簡(jiǎn)單的是把地圖容器背景色設(shè)成和地圖主色調(diào)接近的顏色比如淺灰或淺綠白線視覺上就不明顯了。如果追求更干凈的拼接可以給瓦片圖層加一點(diǎn)負(fù)邊距讓相鄰?fù)咂晕⒅丿B。另一個(gè)容易被忽略的原因是沒有統(tǒng)一scale參數(shù)混用256和512的瓦片會(huì)導(dǎo)致物理尺寸不一致拼接處自然對(duì)不齊。下載參數(shù)保持一致是底線。5.3 并發(fā)過高被限流403與429的處理下載腳本跑了一陣突然成片失敗日志里全是403或429說明瓦片服務(wù)器已經(jīng)識(shí)別到請(qǐng)求頻率異常臨時(shí)把請(qǐng)求拒掉了。處理手段有三層一是把并發(fā)線程數(shù)降下來單IP 8個(gè)線程是相對(duì)安全的值超過10就容易被盯上二是給每個(gè)請(qǐng)求帶Referer: https://www.amap.com/模擬瀏覽器來源三是做好重試退避遇到403/429先等幾秒再重試不要反復(fù)快速請(qǐng)求。還有個(gè)實(shí)戰(zhàn)小技巧任務(wù)順序不要完全固定可以在任務(wù)列表里隨機(jī)打亂一下。太規(guī)律的并發(fā)模式容易被識(shí)別成批量程序稍微加點(diǎn)隨機(jī)性被限流的概率會(huì)低很多。我早期做下載器時(shí)沒注意這點(diǎn)連續(xù)兩次被限流后來加了個(gè)隨機(jī)shuffle再?zèng)]遇到過。5.4 瓦片數(shù)量估算與范圍規(guī)劃下載前先算瓦片數(shù)量這個(gè)習(xí)慣能救你很多次。我遇到過一個(gè)需求方張口就要全市所有級(jí)別的瓦片一算數(shù)據(jù)量幾十TB顯然不現(xiàn)實(shí)。后來把方案改成分級(jí)分區(qū)域下載主城區(qū)15到17級(jí)遠(yuǎn)郊區(qū)16到17級(jí)核心重點(diǎn)區(qū)域單獨(dú)補(bǔ)18級(jí)。這樣既滿足業(yè)務(wù)要求磁盤和帶寬也可控。判斷經(jīng)驗(yàn)一句話局域網(wǎng)內(nèi)網(wǎng)靜態(tài)服務(wù)加載瓦片非?？炱款i從來不是帶寬而是瓦片準(zhǔn)備得夠不夠全、夠不夠細(xì)。寧可把高一級(jí)的瓦片范圍縮小也不要為了省事只下低級(jí)別等業(yè)務(wù)真的需要縮放時(shí)再補(bǔ)返工成本更高。5.5 合規(guī)邊界與瓦片更新從一個(gè)方案評(píng)審細(xì)節(jié)說起最后說一個(gè)原則性問題。瓦片數(shù)據(jù)是高德投入成本生產(chǎn)的地圖數(shù)據(jù)受版權(quán)和服務(wù)條款保護(hù)。下載和內(nèi)網(wǎng)本地化使用適用于企業(yè)內(nèi)部系統(tǒng)、隔離網(wǎng)絡(luò)下的技術(shù)方案、已經(jīng)獲得授權(quán)的項(xiàng)目等場(chǎng)景。不要把下載下來的瓦片二次分發(fā)、轉(zhuǎn)售或者包裝成商業(yè)服務(wù)對(duì)外提供。動(dòng)手之前先確認(rèn)你的使用場(chǎng)景在授權(quán)范圍內(nèi)技術(shù)手段本身是中性的但使用邊界要自己把握清楚。我的個(gè)人習(xí)慣是在方案評(píng)審階段就把“瓦片來源、授權(quán)情況、更新機(jī)制”寫進(jìn)技術(shù)文檔讓所有參與方心里有數(shù)。內(nèi)網(wǎng)地圖的核心問題從來不只是怎么下載而是你有沒有一套可維護(hù)的瓦片更新和校驗(yàn)流程。先把本次范圍下好跑通鏈路后續(xù)需要增量更新時(shí)只要把邊界框和級(jí)別參數(shù)改一改重新跑一遍下載器就行。整套流程越簡(jiǎn)單越不容易出錯(cuò)。這套方法在后來幾個(gè)內(nèi)網(wǎng)大屏項(xiàng)目里反復(fù)用每次都是最省心的那一塊。