布GDB全流程：GDAL直讀、格式轉(zhuǎn)換與運(yùn)維)
1. GeoServer 讀不了 .gdb 文件夾先把原因刨到底很多人第一次把 GDB 數(shù)據(jù)往 GeoServer 上掛的時(shí)候遇到的畫面都差不多在新建數(shù)據(jù)存儲里翻遍了所有選項(xiàng)找不到一個(gè)叫 File Geodatabase 的類型或者硬著頭皮把.gdb目錄的路徑填進(jìn)去點(diǎn)保存GeoServer 彈一個(gè)紅色報(bào)錯(cuò)提示 URL 無法識別。這里需要先把一件事說清楚GeoServer 本身并不具備解析 GDB 二進(jìn)制格式的能力它能讀什么格式完全取決于裝了哪些數(shù)據(jù)存儲擴(kuò)展。GDB 是私有二進(jìn)制格式規(guī)范由商業(yè) GIS 廠商制定開源棧里能讀它的那條路本質(zhì)上繞不開 GDAL/OGR 這一層翻譯層。搞明白這一點(diǎn)后面的所有操作才有方向感。我見過不少人拿著一個(gè)幾十 GB 的 GDB試圖直接改后綴、改連接參數(shù)、甚至把整個(gè).gdb目錄壓成 zip 再上傳折騰一下午也沒進(jìn)展根子就在于把發(fā)布服務(wù)誤解成了上傳文件。GeoServer 發(fā)布圖層的本質(zhì)是它需要一條能持續(xù)訪問數(shù)據(jù)的連接并且這條連接的驅(qū)動棧認(rèn)識這種格式。GDB 恰好卡在第二點(diǎn)上。1.1 GDB 不是一個(gè)文件而是一套目錄約定先糾正一個(gè)非常常見的認(rèn)知偏差。.gdb在文件管理器里顯示成一個(gè)帶數(shù)據(jù)庫圖標(biāo)的文件夾點(diǎn)進(jìn)去是一堆名字像a00000001.gdbtable、a00000003.gdbtablx、gdb這樣的文件。這不是壓縮包也不是可以隨便拷一半走的目錄。它是一個(gè)小型的關(guān)系型存儲幾何、屬性、空間索引、域、子類型、關(guān)系類全在里面靠一套內(nèi)部表結(jié)構(gòu)組織起來。目錄里少一個(gè).gdbtablx整個(gè)數(shù)據(jù)集可能就讀不出空間索引.gdb目錄還在被別的進(jìn)程占用時(shí)你去復(fù)制它拷出來的可能是殘缺的。這個(gè)特性直接決定了兩件事。第一GDB 適合被 GDAL 這類專門的庫一次性讀懂不適合被 GeoServer 直接當(dāng)文件打開。第二任何轉(zhuǎn)換動作都應(yīng)該是先讀全量、再寫出目標(biāo)格式中途斷掉會得到一個(gè)半成品比沒轉(zhuǎn)換更麻煩。還有一個(gè)隱藏細(xì)節(jié)GDB 內(nèi)部字符串默認(rèn)是 UTF-8 存儲的但字段名長度、別名、域值這些東西在轉(zhuǎn)換成其他格式時(shí)經(jīng)常會丟失。所以轉(zhuǎn)換前必須做一次數(shù)據(jù)體檢把圖層清單、字段清單、坐標(biāo)系、要素?cái)?shù)量全部摸一遍不然后面在 GeoServer 里發(fā)現(xiàn)字段少了、坐標(biāo)系錯(cuò)了回頭重來一遍的成本比體檢高十倍。1.2 GeoServer 的讀取能力來自哪里GeoServer 的數(shù)據(jù)存儲是一個(gè)插件化的注冊表。裝完主程序默認(rèn)能讀 Shapefile、GeoPackage、PostGIS、MySQL、WFS 等GDAL、OGR、Oracle、SQL Server 這些統(tǒng)統(tǒng)是擴(kuò)展包得單獨(dú)下 zip解壓到WEB-INF/lib然后重啟。所以你在界面上看不到 GDB 選項(xiàng)不是操作錯(cuò)了是擴(kuò)展沒裝。這里有個(gè)容易混淆的點(diǎn)GeoServer 官方提供的 GDAL 擴(kuò)展里面其實(shí)同時(shí)包含柵格 GDAL 支持和矢量 OGR 支持。矢量那部分才是我們關(guān)心的它的底層就是調(diào)用本機(jī)的 GDAL 動態(tài)庫Windows 上是gdal3xx.dll這一套Linux 上是libgdal.so。也就是說GeoServer 不自己解析 GDB它把活外包給了本機(jī)的 GDAL。這就解釋了為什么很多人裝完插件還是報(bào)錯(cuò)——插件裝了本機(jī) GDAL 沒裝或者裝了但 Java 找不到它。提示判斷到底卡在哪一層有個(gè)很省事的辦法。先在命令行用ogrinfo打開同一個(gè) GDB如果命令行也失敗問題在 GDAL/數(shù)據(jù)本身命令行成功而 GeoServer 失敗問題在插件、環(huán)境變量或 Java 的本地庫加載路徑上。這個(gè)二分法能省掉大量瞎猜。1.3 兩條可行路線直讀插件和格式轉(zhuǎn)換把思路收斂一下實(shí)際可走的就是兩條路。第一條是直讀給 GeoServer 裝 GDAL/OGR 擴(kuò)展配好本機(jī) GDAL 環(huán)境變量讓數(shù)據(jù)存儲直接指向.gdb目錄。優(yōu)點(diǎn)是數(shù)據(jù)不落地、改一處看一處缺點(diǎn)是環(huán)境依賴重、版本咬合緊、只讀場景下還行寫入基本別想。第二條是轉(zhuǎn)換后發(fā)布用ogr2ogr把 GDB 里的目標(biāo)圖層轉(zhuǎn)成 GeoPackage 或灌進(jìn) PostGIS然后 GeoServer 發(fā)布這個(gè)中間產(chǎn)物。優(yōu)點(diǎn)是部署干凈、性能可控、跨機(jī)器遷移簡單缺點(diǎn)是數(shù)據(jù)有副本需要一套更新機(jī)制。這兩條路不存在哪個(gè)更高級只有你的場景更適合哪個(gè)。下一節(jié)我把選型邏輯掰開講因?yàn)檫@一步選錯(cuò)后面所有操作都是給錯(cuò)誤方案打補(bǔ)丁。2. 直讀還是先轉(zhuǎn)格式三條路線的實(shí)際成本對照我做過不少類似的項(xiàng)目從一開始的能直讀就別轉(zhuǎn)慢慢變成了生產(chǎn)環(huán)境一律先轉(zhuǎn)。這個(gè)轉(zhuǎn)變不是技術(shù)偏好是被運(yùn)維成本教育出來的。下面這張表是這幾年的經(jīng)驗(yàn)匯總參數(shù)不是拍腦袋是實(shí)際折騰過的時(shí)間成本估算。維度GDB 直讀GDAL 擴(kuò)展轉(zhuǎn) GeoPackage 后發(fā)布灌入 PostGIS 后發(fā)布部署復(fù)雜度高需匹配 GDAL 版本與 Java 本地庫低GeoServer 原生支持中需數(shù)據(jù)庫服務(wù)首次配置耗時(shí)半天到兩天一小時(shí)內(nèi)半天讀取性能大圖層中等每次查詢都要穿過 OGR良好優(yōu)秀有真索引數(shù)據(jù)更新直接替換 GDB 目錄替換單文件 gpkg增量 SQL 或重新導(dǎo)入并發(fā)能力一般文件鎖是隱患一般強(qiáng)字段名保留完整完整完整遷移到別的機(jī)器極麻煩環(huán)境要重建復(fù)制一個(gè)文件備份恢復(fù)即可適合場景一次性出圖、臨時(shí)演示中小體量固定數(shù)據(jù)、單機(jī)部署長期運(yùn)行、多圖層、多用戶2.1 為什么直讀路線的隱性成本最高表面上看直讀最干凈——數(shù)據(jù)不需要復(fù)制原件更新了服務(wù)就跟著更新。但實(shí)際落地時(shí)成本集中在三個(gè)地方。第一是版本咬合。GeoServer 的 GDAL 擴(kuò)展會依賴特定大版本的 GDAL比如某個(gè) GeoServer 版本配套的是 GDAL 3.x 某一系列你本機(jī)裝了個(gè)更新的或者更老的Java 加載動態(tài)庫時(shí)直接拋UnsatisfiedLinkError或者加載成功但驅(qū)動列表為空。這個(gè)報(bào)錯(cuò)信息非常不友好經(jīng)常只說找不到 native library不說到底缺哪個(gè)。第二是環(huán)境變量。GDAL 需要GDAL_DATA指向投影定義數(shù)據(jù)目錄PROJ_LIB指向 PROJ 的轉(zhuǎn)換參數(shù)庫。這兩個(gè)變量在命令行里設(shè)好了不代表 GeoServer 的啟動進(jìn)程能繼承到——尤其是 Windows 下用服務(wù)方式啟動、或者用容器啟動的時(shí)候。我見過最典型的情況命令行ogrinfo一切正常GeoServer 里選 GDB 就報(bào)無法識別坐標(biāo)系。第三是文件鎖與并發(fā)。GDB 在讀取時(shí)會持有目錄層面的句柄如果同時(shí)有別的東西比如桌面軟件、同步盤、備份腳本在動這個(gè)目錄GeoServer 的查詢會間歇性失敗而且失敗得很隨機(jī)日志里看不出規(guī)律。2.2 什么情況下直讀仍然值得也不是全盤否定。有這么幾種場景我依然會選直讀。一種是臨時(shí)演示或驗(yàn)收?？蛻衄F(xiàn)場要求服務(wù)必須直連原始數(shù)據(jù)庫不能有中間副本那你只能硬著頭皮上插件。這種場景通常數(shù)據(jù)量不大、并發(fā)很低把環(huán)境配好就行。另一種是數(shù)據(jù)天天變、且變化是整庫替換。轉(zhuǎn)格式每次都要跑一遍全量幾十 GB 的數(shù)據(jù)轉(zhuǎn)換加索引重建要按小時(shí)計(jì)而直讀只需要替換 GDB 目錄再清一下 GeoServer 的緩存。這種高頻全量替換的場景直讀反而省事。還有一種是你已經(jīng)在用 GDAL 生態(tài)做別的事機(jī)器上本來就有一套調(diào)好的 GDAL 環(huán)境插件只是復(fù)用邊際成本接近零。2.3 我為什么在長期項(xiàng)目里優(yōu)先選 PostGIS說個(gè)實(shí)在話只要圖層數(shù)量超過十幾個(gè)、或者有多個(gè)前端同時(shí)在拉 WMS/WFS我就直接上 PostGIS。原因很簡單GeoServer 的很多能力只有在關(guān)系型數(shù)據(jù)源上才是完整的。比如按屬性過濾的查詢下推、空間索引的自動利用、并發(fā)連接池、CQL 過濾的性能、圖層組的聯(lián)合查詢文件型數(shù)據(jù)源要么做不到要么做得很勉強(qiáng)。GeoPackage 是個(gè)很好的折中——單文件、自帶空間索引、支持 UTF-8、字段名不限長度、GeoServer 原生支持不用裝任何插件。中小體量單圖層幾百萬要素以內(nèi)的固定數(shù)據(jù)我基本都轉(zhuǎn)成 GeoPackage。它的短板是寫入并發(fā)差但發(fā)布地圖服務(wù)本來就是讀多寫少問題不大。提示轉(zhuǎn)換不是二選一的終局決定。我常用的做法是先在 GeoPackage 上把樣式、坐標(biāo)系、字段別名全部調(diào)通驗(yàn)證沒問題后再灌進(jìn) PostGIS 做最終上線。中間那一步只是驗(yàn)證GeoPackage 文件本身不用保留這樣既不浪費(fèi)時(shí)間也不會在上線階段才發(fā)現(xiàn)數(shù)據(jù)有問題。3. 環(huán)境搭建GDAL、插件版本、JVM 路徑三者的咬合關(guān)系如果確定走直讀路線這一節(jié)是最容易翻車的地方。我把踩過的順序整理出來先確認(rèn) GDAL 能用再確認(rèn)驅(qū)動存在再裝插件最后配環(huán)境變量并驗(yàn)證。順序錯(cuò)了排查成本翻倍。3.1 版本對齊是第一道坎去 GeoServer 的下載頁找擴(kuò)展包時(shí)注意下載鏈接是按 GeoServer 版本分目錄的。比如你裝的是 2.24 系列就必須下 2.24 目錄下對應(yīng)小版本的 GDAL 擴(kuò)展跨小版本混用有一定概率出問題——不是必然崩但一旦崩了很難定位因?yàn)閳?bào)錯(cuò)信息通常指向不到版本。另一個(gè)對齊點(diǎn)是 GDAL 大版本。擴(kuò)展包內(nèi)部對 GDAL 的調(diào)用接口是有版本要求的裝一個(gè)差了好幾個(gè)大版本的 GDAL癥狀是插件加載成功、數(shù)據(jù)存儲能建、但一預(yù)覽就報(bào)驅(qū)動不支持。我一般的做法是先在目標(biāo)機(jī)器上把 GDAL 裝好并跑通ogrinfo再去看 GeoServer 日志里打印的 GDAL 版本號兩者能對上再往下走。3.2 安裝 GDAL 并確認(rèn) GDB 驅(qū)動在不在Windows 上用現(xiàn)成的安裝包最省事裝完之后把bin目錄加進(jìn)PATH然后開一個(gè)新的命令行窗口驗(yàn)證ogrinfo --version看到版本號說明主程序通了。接下來是關(guān)鍵一步確認(rèn) GDB 驅(qū)動是否被編譯進(jìn)來ogrinfo --formats | grep -i gdbWindows 命令行沒有 grep用ogrinfo --formats | findstr /i gdb正常應(yīng)該能看到類似OpenFileGDB -vector- (ro): ESRI FileGDB這一行ro表示只讀。這對發(fā)布地圖服務(wù)完全夠用——我們只需要讀。如果這一行沒有說明你裝的 GDAL 構(gòu)建里沒帶這個(gè)驅(qū)動換一個(gè)完整構(gòu)建的安裝包或者用 conda 裝一份帶全部驅(qū)動的 GDAL。這一步不通后面所有的配置都是白做。3.3 裝插件、配變量、驗(yàn)證加載把擴(kuò)展包解壓到 GeoServer 的WEB-INF/lib注意是解壓出來的 jar 直接放進(jìn)去不要留一層目錄。然后處理環(huán)境變量。GeoServer 有兩種啟動方式處理方式不一樣。用startup.bat/startup.sh手動啟動的直接改啟動腳本里的JAVA_OPTS追加-Djava.library.path/path/to/gdal/bin同時(shí)在腳本開頭export GDAL_DATA/path/to/gdal/data和export PROJ_LIB/path/to/gdal/share/projWindows 用set。用服務(wù)方式啟動的環(huán)境變量要配到服務(wù)級別或者干脆改注冊表里的服務(wù)環(huán)境。這一步最容易漏因?yàn)槟阍谧约旱慕K端里配好了變量服務(wù)進(jìn)程根本繼承不到。重啟之后去 GeoServer 的關(guān)于頁面或者日志里搜 GDAL能看到版本信息就說明插件活了。這時(shí)候新建數(shù)據(jù)存儲列表里應(yīng)該出現(xiàn) GDAL 相關(guān)條目。填入 GDB 路徑時(shí)注意格式file:///D:/data/road.gdb三個(gè)斜杠、正斜杠不要用 Windows 的反斜杠直接拼。路徑里有中文或者空格時(shí)我建議先用英文路徑測試通過再回頭處理編碼問題——把兩個(gè)變量同時(shí)引入出問題根本分不清是誰的鍋。注意國內(nèi)很多單位的數(shù)據(jù)目錄帶中文名比如基礎(chǔ)地理數(shù)據(jù)/gdb。GDAL 在 Windows 上對非 ASCII 路徑的支持時(shí)好時(shí)壞具體取決于構(gòu)建時(shí)的字符集設(shè)置。穩(wěn)妥做法是把數(shù)據(jù)復(fù)制到一個(gè)純英文路徑下再發(fā)布或者改用轉(zhuǎn)換路線繞開這個(gè)雷。4. 用 GDAL 把 GDB 拆成可發(fā)布的數(shù)據(jù)體檢、轉(zhuǎn)換、修復(fù)走轉(zhuǎn)換路線的話這一節(jié)是核心操作。我把它拆成體檢、轉(zhuǎn)換、修復(fù)三步每一步都有具體的檢查項(xiàng)別跳。4.1 動手之前先做數(shù)據(jù)體檢體檢的目的很明確搞清楚這個(gè) GDB 里到底有什么哪些能用哪些是坑。ogrinfo -so -al D:/data/road.gdb-so是只輸出摘要不輸出要素-al是列出所有圖層。輸出里要重點(diǎn)看四樣?xùn)|西。圖層數(shù)量與名稱。有些 GDB 里幾十個(gè)圖層其中一大半是注記、關(guān)系類、廢棄圖層。把真正要發(fā)布的挑出來別一股腦全轉(zhuǎn)轉(zhuǎn)完在 GeoServer 里一個(gè)個(gè)配樣式能累死人。幾何類型?？词?Point、LineString、Polygon 還是 Multi 版本混用。GDB 允許一個(gè)圖層里混幾何類型但很多目標(biāo)格式和 GeoServer 的渲染器不喜歡混?；煊玫膱D層要么用PROMOTE_TO_MULTI統(tǒng)一成多部件要么拆開。坐標(biāo)系。輸出里L(fēng)ayer SRS WKT那段能看到 EPSG 或者 WKT 定義。這里有個(gè)高頻坑GDB 里記錄的坐標(biāo)系可能是自定義的、帶七參數(shù)的、甚至只是未定義。如果顯示(unknown)就必須手工指定不能指望它自動識別否則發(fā)布出來位置能偏出去幾百米。要素?cái)?shù)量。Feature Count那行。這個(gè)數(shù)字決定你后面要不要分批轉(zhuǎn)、要不要加進(jìn)度條、轉(zhuǎn)換要等多久。幾百萬要素的圖層ogr2ogr跑起來十幾分鐘很正常。4.2 轉(zhuǎn)成 GeoPackage 的完整命令確認(rèn)完就動手。下面這條是我常用的模板參數(shù)含義后面逐個(gè)解釋ogr2ogr -f GPKG D:/out/road.gpkg D:/data/road.gdb ^ -nln road ^ -nlt PROMOTE_TO_MULTI ^ -t_srs EPSG:4490 ^ -lco SPATIAL_INDEXYES ^ -lco FIDfid ^ -progress-f GPKG指定輸出格式。-nln指定輸出圖層名不起這個(gè)名字的話會沿用原名原名如果帶中文或者特殊字符后面在 GeoServer 里做 CQL 過濾會很難寫。-nlt PROMOTE_TO_MULTI把單部件幾何統(tǒng)一提升為多部件避免混類型導(dǎo)致渲染異常。-t_srs做坐標(biāo)系轉(zhuǎn)換不帶這個(gè)參數(shù)就保持原樣——如果你不確定源坐標(biāo)系千萬別亂加這個(gè)參數(shù)轉(zhuǎn)錯(cuò)了比不轉(zhuǎn)更難查。-lco SPATIAL_INDEXYES建空間索引這個(gè)對 GeoServer 的預(yù)覽和范圍查詢性能影響很大一定要開。-progress就是進(jìn)度顯示大圖層必備。如果只想轉(zhuǎn)其中一個(gè)圖層把 GDB 路徑后面加上圖層名ogr2ogr -f GPKG D:/out/road.gpkg D:/data/road.gdb road如果 GDB 里的圖層名有中文或者空格用引號包起來或者先用ogrinfo確認(rèn)準(zhǔn)確寫法。GDAL 對圖層名大小寫不敏感但對空格和特殊字符敏感。4.3 中文亂碼、字段截?cái)?、日期類型的具體處理這三個(gè)問題是 GDB 轉(zhuǎn)換途中最常見的數(shù)據(jù)看著轉(zhuǎn)了、用起來不對。中文亂碼。GeoPackage 內(nèi)部就是 UTF-8轉(zhuǎn)換過程中一般不會亂。真正會亂的是轉(zhuǎn)成 Shapefile 的時(shí)候——Shapefile 需要.cpg文件聲明編碼。如果目標(biāo)格式必須是 Shapefile加上-lco ENCODINGUTF-8并且在 GeoServer 里發(fā)布時(shí)把字符集也設(shè)成 UTF-8兩邊不一致就會出現(xiàn)屬性表里全是問號。我的建議是能不用 Shapefile 就別用字段名 10 字符限制、字段數(shù) 255 限制、日期類型丟失坑太多了。字段名截?cái)?。這個(gè)只在 Shapefile 出現(xiàn)。GDB 里叫ROAD_NAME_FULL的字段轉(zhuǎn)成 Shapefile 會變成ROAD_NAME_兩個(gè)字段如果前 10 個(gè)字符一樣直接沖突報(bào)錯(cuò)。GeoPackage 和 PostGIS 都沒這個(gè)問題這也是我推薦它們的原因之一。日期類型。GDB 里日期字段轉(zhuǎn)出來經(jīng)常變成字符串或者變成一個(gè)奇怪的時(shí)間戳。這會導(dǎo)致 GeoServer 的 WMS 時(shí)間維度功能用不了。轉(zhuǎn)換時(shí)可以用-mapFieldType DateString顯式指定策略或者干脆在轉(zhuǎn)換后用 SQL 在 PostGIS 里改類型。GeoPackage 的日期支持相對好一些但 GeoServer 讀出來的類型仍需要在圖層配置頁確認(rèn)一眼。4.4 幾何有效性修復(fù)與自相交處理GDB 里的面數(shù)據(jù)經(jīng)常有自相交、環(huán)方向錯(cuò)誤、零面積多邊形這些問題。它們在桌面軟件里能顯示但 GeoServer 的渲染器對無效幾何的容忍度低癥狀是某些多邊形消失、或者填充區(qū)域莫名其妙地連成一片。GDAL 3.4 之后ogr2ogr支持-makevalid直接修ogr2ogr -f GPKG D:/out/parcel.gpkg D:/data/parcel.gdb parcel -makevalid -nlt MULTIPOLYGON如果你的 GDAL 版本不支持退化方案是先轉(zhuǎn)出來再用ST_MakeValid在數(shù)據(jù)庫里修或者用 QGIS 的修復(fù)幾何工具批量處理。別指望 GeoServer 幫你兜底它不會。還有一個(gè)不起眼但很致命的點(diǎn)空幾何。有些圖層里混著幾何為 NULL 的記錄轉(zhuǎn)出來之后 GeoServer 在統(tǒng)計(jì)范圍時(shí)可能算出個(gè)無效的包圍盒導(dǎo)致圖層預(yù)覽一片空白你以為是樣式問題其實(shí)是范圍錯(cuò)了。轉(zhuǎn)換時(shí)加-where SHAPE IS NOT NULL過濾掉或者轉(zhuǎn)完之后在目標(biāo)庫里DELETE FROM xxx WHERE geom IS NULL。5. 在 GeoServer 里把圖層真正掛上去數(shù)據(jù)準(zhǔn)備好了接下來是在 GeoServer 里走一遍完整流程。這一段看起來是點(diǎn)點(diǎn)鼠標(biāo)但有幾個(gè)必改項(xiàng)改漏了后面全是麻煩。5.1 新建數(shù)據(jù)存儲的填寫要點(diǎn)進(jìn)數(shù)據(jù)→新建數(shù)據(jù)存儲選 GeoPackage或者 PostGIS。GeoPackage 的路徑填法和 GDB 一樣file:///D:/out/road.gpkg注意格式。PostGIS 則填主機(jī)、端口、庫名、用戶名密碼這些沒什么好說的但有一個(gè)參數(shù)值得調(diào)連接池的min connections和max connections。默認(rèn)值偏保守并發(fā)上來之后會出現(xiàn)等待連接超時(shí)把 max 調(diào)到 20 左右視機(jī)器而定會穩(wěn)很多。工作區(qū)Workspace的選擇不是隨便點(diǎn)。它的作用相當(dāng)于命名空間后面 WMS 請求里的圖層名會是工作區(qū):圖層名。我習(xí)慣按項(xiàng)目或按數(shù)據(jù)主題劃分工作區(qū)別把所有東西堆在默認(rèn)工作區(qū)里后期做權(quán)限控制和圖層組的時(shí)候會感謝自己。5.2 圖層發(fā)布頁面里必須改的幾項(xiàng)點(diǎn)發(fā)布之后進(jìn)入配置頁這一頁信息很多但真正必須確認(rèn)的就幾個(gè)。坐標(biāo)系聲明。Native SRS是數(shù)據(jù)本身的坐標(biāo)系Declared SRS是對外聲明的坐標(biāo)系。這兩個(gè)如果不一致GeoServer 會做動態(tài)投影。絕大多數(shù)情況下應(yīng)該讓兩者一致把 Declared 設(shè)成跟 Native 一樣然后靠 WMS 請求里的SRS參數(shù)控制輸出投影。我曾經(jīng)遇到一個(gè)案例數(shù)據(jù)是投影坐標(biāo)Declared 被誤設(shè)成了經(jīng)緯度結(jié)果前端拿到的圖整體壓縮變形排查了半天才發(fā)現(xiàn)是這個(gè)字段。邊框Bounding Box。點(diǎn)從數(shù)據(jù)中計(jì)算和從原生邊框計(jì)算兩個(gè)按鈕。如果算出來是0,0,-1,-1這種明顯不對的值說明數(shù)據(jù)里有空幾何或者坐標(biāo)系識別錯(cuò)誤回去查數(shù)據(jù)。邊框錯(cuò)了WMS 的BBOX請求會返回空白圖而且不報(bào)錯(cuò)最難排查。屬性勾選。Queryable要勾上否則 WFS 查詢不返回屬性。屬性列表里把不需要對外暴露的字段比如內(nèi)部 ID、敏感備注取消勾選減少傳輸量也順便做了脫敏。5.3 樣式手寫 SLD 還是從桌面軟件導(dǎo)出樣式這一塊我的實(shí)際經(jīng)驗(yàn)是簡單的單色/分級渲染直接在 GeoServer 里用界面生成復(fù)雜的多比例尺、標(biāo)注避讓、圖標(biāo)符號用桌面軟件配好再導(dǎo)出 SLD。界面生成的樣式存在 GeoServer 自己的樣式庫里改起來簡單但表達(dá)力有限。導(dǎo)出 SLD 的好處是所見即所得缺點(diǎn)是導(dǎo)出文件里常常帶一堆冗余定義而且不同版本的導(dǎo)出格式細(xì)節(jié)有差異導(dǎo)入時(shí)報(bào)錯(cuò)的話得手工改。幾個(gè)實(shí)戰(zhàn)要點(diǎn)標(biāo)注Label一定要設(shè)label和font并且配一個(gè)VendorOption控制重疊比如conflictResolutionfalse加spaceAround10否則密集路網(wǎng)的標(biāo)注會糊成一團(tuán)。分級渲染用Intervals比一堆Rule好維護(hù)。圖層如果要素特別多樣式里加VendorOption maxDisplacement之類能明顯降低渲染耗時(shí)。5.4 預(yù)覽驗(yàn)證與切片緩存發(fā)布完之后不要只看圖層預(yù)覽里的 OpenLayers 頁面。那個(gè)頁面會帶上一堆默認(rèn)參數(shù)有時(shí)候恰好繞過了問題。我一般用三步驗(yàn)證OpenLayers 預(yù)覽看整體、GetFeatureInfo請求看屬性對不對、直接拼一個(gè)指定BBOX和SRS的GetMap請求看投影轉(zhuǎn)換有沒有偏。都通過之后再上切片。切片的圖層組方案要和前端的底圖對齊GridSet里的坐標(biāo)系、分辨率層級、瓦片尺寸必須和前端一致不一致就會出現(xiàn)瓦片錯(cuò)位——放大時(shí)圖是清楚的一縮小就整體偏移半屏。緩存建好之后數(shù)據(jù)更新的那天記得清緩存不然前端看到的還是舊圖。6. 踩過的坑六個(gè)真實(shí)翻車現(xiàn)場與排查鏈路這一節(jié)是這篇文章里我最想寫的部分因?yàn)榍懊婺切┎襟E文檔里都能查到下面這些是查不到、只能踩出來的。6.1 插件裝了但驅(qū)動列表是空的癥狀數(shù)據(jù)存儲能建出來選 GDAL 類型路徑填對點(diǎn)保存報(bào)無法創(chuàng)建數(shù)據(jù)存儲。排查鏈路先看 GeoServer 日志搜 GDAL如果只有一行版本號沒有驅(qū)動列表說明本地庫加載了但驅(qū)動初始化失敗。最常見原因是GDAL_DATA沒指向正確目錄GDAL 找不到gcs.csv、proj.db這些數(shù)據(jù)文件。修復(fù)方法是把GDAL_DATA指向 GDAL 安裝目錄下的data新版可能在share/gdalPROJ_LIB指向share/proj重啟進(jìn)程再看日志。還有一個(gè)更隱蔽的原因機(jī)器上裝了多個(gè) GDAL比如 Python 環(huán)境里一份、獨(dú)立安裝一份PATH里排在前面的那個(gè)版本和插件要求的不一致。用where gdalinfo看一眼到底用的哪一份把不對的從PATH里挪走。6.2 圖層預(yù)覽一片空白日志沒有任何報(bào)錯(cuò)這是最消耗耐心的一類問題。排查順序我固定成四步。第一步看圖層配置頁的邊框是不是有效值。是0,0,-1,-1就說明數(shù)據(jù)范圍沒算出來回去查幾何和坐標(biāo)系。第二步用ogrinfo -al -geomSUMMARY打開源數(shù)據(jù)看第一條要素的坐標(biāo)大概是多少。如果坐標(biāo)是幾百、幾千量級說明是投影坐標(biāo)如果是 100 多、30 多說明是經(jīng)緯度。兩種情況下圖層配置里的 Native SRS 必須對得上。第三步手工拼 GetMap 請求把SRS、BBOX、WIDTH、HEIGHT全部顯式寫上看返回的 PNG 是不是全透明。第四步如果前三步都對但還是空檢查樣式。用一個(gè)最簡單的PolygonSymbolizer純紅色測試排除樣式表達(dá)式寫錯(cuò)導(dǎo)致的渲染失敗。6.3 大字段和 BLOB 讓渲染慢到無法接受GDB 里經(jīng)常帶照片、附件、超長備注這類字段。轉(zhuǎn)出來之后這些字段還在GeoServer 在生成要素時(shí)會把它們一起讀出來即使樣式根本用不到。一個(gè)幾萬要素的圖層帶 BLOB 字段單次 GetMap 能慢到十幾秒。解決辦法很直接轉(zhuǎn)換時(shí)就不帶這些字段。ogr2ogr支持-selectogr2ogr -f GPKG D:/out/poi.gpkg D:/data/poi.gdb poi -select name,type,lng,lat-select里只寫要保留的字段其他一律不轉(zhuǎn)。如果字段已經(jīng)轉(zhuǎn)出來了在 PostGIS 里ALTER TABLE ... DROP COLUMN更快。這一步做完同一個(gè)圖層的出圖時(shí)間能從十幾秒降到一秒以內(nèi)。6.4 WMS 出圖中文標(biāo)注變成方塊這個(gè)問題的根源是字體。GeoServer 渲染標(biāo)注時(shí)用的是服務(wù)端字體如果 SLD 里指定的字體在服務(wù)器上不存在就會 fallback 到一個(gè)沒有中文字形的字體渲染出來全是方塊或者豆腐塊。修復(fù)分兩步先確認(rèn)服務(wù)器上裝了中文字體Linux 下把字體文件放進(jìn)/usr/share/fonts再fc-cache -fv然后在 SLD 里把font-family設(shè)成一個(gè)確定存在的字體名。GeoServer 后臺有個(gè)字體列表頁面能看到當(dāng)前能用的字體SLD 里寫的名字必須在這個(gè)列表里。我一般會寫一個(gè)字體棧比如先寫主字體再寫 fallback但 GeoServer 對字體棧的支持不如瀏覽器穩(wěn)定實(shí)測還是指定單一存在的字體最可靠。6.5 時(shí)間字段變成字符串時(shí)間維度功能失效前面提過日期類型轉(zhuǎn)換會丟。這個(gè)問題在發(fā)布帶時(shí)間維度的服務(wù)時(shí)會集中爆發(fā)——GeoServer 的 WMS 時(shí)間維度要求字段是java.sql.Timestamp或者Date如果是字符串配置頁面里那個(gè)時(shí)間選項(xiàng)卡根本不會出現(xiàn)。修復(fù)方式取決于目標(biāo)庫。PostGIS 里可以直接ALTER TABLE t ALTER COLUMN dt TYPE timestamp USING dt::timestamp前提是字符串格式規(guī)范。GeoPackage 里類型改起來麻煩通常的做法是轉(zhuǎn)換時(shí)就用-mapFieldType強(qiáng)制指定或者在桌面軟件里先規(guī)范格式。我遇到過一次數(shù)據(jù)里的日期是2023/5/1這種非標(biāo)準(zhǔn)寫法轉(zhuǎn)出來之后解析失敗全變 NULL最后是用 SQL 逐條清洗的。6.6 面圖層自相交導(dǎo)致部分要素不渲染前面提到過-makevalid這里說一個(gè)更細(xì)的坑有些自相交在轉(zhuǎn)換時(shí)被修成了空幾何。修完之后要素?cái)?shù)量沒變但幾何是空的GeoServer 渲染時(shí)直接跳過看起來就像是某些地塊憑空消失了。排查方法是轉(zhuǎn)完之后統(tǒng)計(jì)空幾何數(shù)量SELECT count(*) FROM parcel WHERE geom IS NULL OR ST_IsEmpty(geom);不為零就說明有要素被修沒了。處理方式有兩種要么回頭在源數(shù)據(jù)里手工修這幾個(gè)要素通常數(shù)量不多要么接受丟失但記錄下來。我一般選前者因?yàn)槊鏀?shù)據(jù)丟一個(gè)業(yè)務(wù)上可能就是一塊地沒了。7. 服務(wù)上線之后的三件運(yùn)維事發(fā)布成功只是開始真正讓人熬夜的是上線之后。這三件事我在每個(gè)項(xiàng)目里都會提前處理。7.1 連接池與 JVM 內(nèi)存GeoServer 默認(rèn)的 JVM 堆內(nèi)存偏小幾個(gè)大圖層一起渲染就容易OutOfMemoryError。啟動腳本里把-Xmx調(diào)大具體值看機(jī)器內(nèi)存一般給到物理內(nèi)存的一半以內(nèi)比較穩(wěn)。但要注意堆開太大Full GC 的時(shí)間也會變長反而造成請求卡頓所以不是越大越好。連接池方面文件型數(shù)據(jù)源GeoPackage沒有連接池概念但 PostGIS 有。max connections別設(shè)太高超過數(shù)據(jù)庫端的連接上限會直接拒絕。這個(gè)值我一般按前端并發(fā)數(shù) × 1.5估然后壓測驗(yàn)證。另外記得開validate connections數(shù)據(jù)庫重啟之后連接池能自動恢復(fù)不然會出現(xiàn)服務(wù)活著但所有查詢都失敗的情況。7.2 切片方案與緩存失效切片是性能和體驗(yàn)的分水嶺。有緩存和沒緩存同一個(gè)圖層的首屏?xí)r間差一個(gè)數(shù)量級。但切片有個(gè)前提圖層組、坐標(biāo)系、分辨率層級、瓦片尺寸必須和前端底圖完全一致。差一點(diǎn)都不行表現(xiàn)出來就是偏移或者縮放層級錯(cuò)亂。緩存失效策略我通常配成兩種按圖層手動清以及按區(qū)域清。數(shù)據(jù)更新頻率低的更新完手動清一次就行更新頻繁的用 GeoServer 的 REST 接口在數(shù)據(jù)導(dǎo)入流程結(jié)束后自動觸發(fā)清理比人肉操作可靠。注意清緩存的時(shí)候別忘了 GeoServer 還有一層要素緩存配置頁里的Queryable附近有個(gè)緩存設(shè)置。圖層元數(shù)據(jù)緩存不清改完數(shù)據(jù)可能還是舊的范圍和要素?cái)?shù)看著像數(shù)據(jù)沒更新其實(shí)是緩存騙了你。7.3 數(shù)據(jù)更新的落地策略轉(zhuǎn)換路線的最大痛點(diǎn)是數(shù)據(jù)不是實(shí)時(shí)的。所以必須提前設(shè)計(jì)更新流程而不是等業(yè)務(wù)方問為什么昨天的圖還沒變才想。我的常規(guī)做法是保留一套腳本ogr2ogr轉(zhuǎn)換帶-append參數(shù)做增量追加前提是源數(shù)據(jù)有穩(wěn)定主鍵或者整表DROP后重建數(shù)據(jù)量不大時(shí)更簡單可靠。腳本跑完自動調(diào) GeoServer 的 REST 接口刷新數(shù)據(jù)存儲、清圖層緩存。整套流程串起來更新就是從人工操作半小時(shí)變成跑個(gè)任務(wù)等幾分鐘。如果數(shù)據(jù)源是別人提供的、更新時(shí)機(jī)不可控那就得在前端或者圖層配置里給個(gè)數(shù)據(jù)截止時(shí)間的說明至少讓使用者心里有數(shù)。這個(gè)細(xì)節(jié)看著不起眼但能省掉大量你們數(shù)據(jù)不對的扯皮。最后說一句個(gè)人體會GDB 轉(zhuǎn) GeoServer 這件事技術(shù)難度其實(shí)不高難的是把數(shù)據(jù)本身的問題摸清楚。我做過這么多類似的項(xiàng)目真正卡住人的從來不是插件裝不上而是坐標(biāo)系是自定義的、幾何是壞的、字段是重復(fù)的、編碼是亂的。所以每次開工我都會花半小時(shí)把ogrinfo的輸出從頭到尾讀一遍把可疑的地方記下來先處理掉。這半小時(shí)往往能把后面三天的返工省下來。 GeoServer發(fā)布GDB全流程：GDAL直讀、格式轉(zhuǎn)換與運(yùn)維
1. GeoServer 讀不了 .gdb 文件夾先把原因刨到底很多人第一次把 GDB 數(shù)據(jù)往 GeoServer 上掛的時(shí)候遇到的畫面都差不多在新建數(shù)據(jù)存儲里翻遍了所有選項(xiàng)找不到一個(gè)叫 File Geodatabase 的類型或者硬著頭皮把.gdb目錄的路徑填進(jìn)去點(diǎn)保存GeoServer 彈一個(gè)紅色報(bào)錯(cuò)提示 URL 無法識別。這里需要先把一件事說清楚GeoServer 本身并不具備解析 GDB 二進(jìn)制格式的能力它能讀什么格式完全取決于裝了哪些數(shù)據(jù)存儲擴(kuò)展。GDB 是私有二進(jìn)制格式規(guī)范由商業(yè) GIS 廠商制定開源棧里能讀它的那條路本質(zhì)上繞不開 GDAL/OGR 這一層翻譯層。搞明白這一點(diǎn)后面的所有操作才有方向感。我見過不少人拿著一個(gè)幾十 GB 的 GDB試圖直接改后綴、改連接參數(shù)、甚至把整個(gè).gdb目錄壓成 zip 再上傳折騰一下午也沒進(jìn)展根子就在于把發(fā)布服務(wù)誤解成了上傳文件。GeoServer 發(fā)布圖層的本質(zhì)是它需要一條能持續(xù)訪問數(shù)據(jù)的連接并且這條連接的驅(qū)動棧認(rèn)識這種格式。GDB 恰好卡在第二點(diǎn)上。1.1 GDB 不是一個(gè)文件而是一套目錄約定先糾正一個(gè)非常常見的認(rèn)知偏差。.gdb在文件管理器里顯示成一個(gè)帶數(shù)據(jù)庫圖標(biāo)的文件夾點(diǎn)進(jìn)去是一堆名字像a00000001.gdbtable、a00000003.gdbtablx、gdb這樣的文件。這不是壓縮包也不是可以隨便拷一半走的目錄。它是一個(gè)小型的關(guān)系型存儲幾何、屬性、空間索引、域、子類型、關(guān)系類全在里面靠一套內(nèi)部表結(jié)構(gòu)組織起來。目錄里少一個(gè).gdbtablx整個(gè)數(shù)據(jù)集可能就讀不出空間索引.gdb目錄還在被別的進(jìn)程占用時(shí)你去復(fù)制它拷出來的可能是殘缺的。這個(gè)特性直接決定了兩件事。第一GDB 適合被 GDAL 這類專門的庫一次性讀懂不適合被 GeoServer 直接當(dāng)文件打開。第二任何轉(zhuǎn)換動作都應(yīng)該是先讀全量、再寫出目標(biāo)格式中途斷掉會得到一個(gè)半成品比沒轉(zhuǎn)換更麻煩。還有一個(gè)隱藏細(xì)節(jié)GDB 內(nèi)部字符串默認(rèn)是 UTF-8 存儲的但字段名長度、別名、域值這些東西在轉(zhuǎn)換成其他格式時(shí)經(jīng)常會丟失。所以轉(zhuǎn)換前必須做一次數(shù)據(jù)體檢把圖層清單、字段清單、坐標(biāo)系、要素?cái)?shù)量全部摸一遍不然后面在 GeoServer 里發(fā)現(xiàn)字段少了、坐標(biāo)系錯(cuò)了回頭重來一遍的成本比體檢高十倍。1.2 GeoServer 的讀取能力來自哪里GeoServer 的數(shù)據(jù)存儲是一個(gè)插件化的注冊表。裝完主程序默認(rèn)能讀 Shapefile、GeoPackage、PostGIS、MySQL、WFS 等GDAL、OGR、Oracle、SQL Server 這些統(tǒng)統(tǒng)是擴(kuò)展包得單獨(dú)下 zip解壓到WEB-INF/lib然后重啟。所以你在界面上看不到 GDB 選項(xiàng)不是操作錯(cuò)了是擴(kuò)展沒裝。這里有個(gè)容易混淆的點(diǎn)GeoServer 官方提供的 GDAL 擴(kuò)展里面其實(shí)同時(shí)包含柵格 GDAL 支持和矢量 OGR 支持。矢量那部分才是我們關(guān)心的它的底層就是調(diào)用本機(jī)的 GDAL 動態(tài)庫Windows 上是gdal3xx.dll這一套Linux 上是libgdal.so。也就是說GeoServer 不自己解析 GDB它把活外包給了本機(jī)的 GDAL。這就解釋了為什么很多人裝完插件還是報(bào)錯(cuò)——插件裝了本機(jī) GDAL 沒裝或者裝了但 Java 找不到它。提示判斷到底卡在哪一層有個(gè)很省事的辦法。先在命令行用ogrinfo打開同一個(gè) GDB如果命令行也失敗問題在 GDAL/數(shù)據(jù)本身命令行成功而 GeoServer 失敗問題在插件、環(huán)境變量或 Java 的本地庫加載路徑上。這個(gè)二分法能省掉大量瞎猜。1.3 兩條可行路線直讀插件和格式轉(zhuǎn)換把思路收斂一下實(shí)際可走的就是兩條路。第一條是直讀給 GeoServer 裝 GDAL/OGR 擴(kuò)展配好本機(jī) GDAL 環(huán)境變量讓數(shù)據(jù)存儲直接指向.gdb目錄。優(yōu)點(diǎn)是數(shù)據(jù)不落地、改一處看一處缺點(diǎn)是環(huán)境依賴重、版本咬合緊、只讀場景下還行寫入基本別想。第二條是轉(zhuǎn)換后發(fā)布用ogr2ogr把 GDB 里的目標(biāo)圖層轉(zhuǎn)成 GeoPackage 或灌進(jìn) PostGIS然后 GeoServer 發(fā)布這個(gè)中間產(chǎn)物。優(yōu)點(diǎn)是部署干凈、性能可控、跨機(jī)器遷移簡單缺點(diǎn)是數(shù)據(jù)有副本需要一套更新機(jī)制。這兩條路不存在哪個(gè)更高級只有你的場景更適合哪個(gè)。下一節(jié)我把選型邏輯掰開講因?yàn)檫@一步選錯(cuò)后面所有操作都是給錯(cuò)誤方案打補(bǔ)丁。2. 直讀還是先轉(zhuǎn)格式三條路線的實(shí)際成本對照我做過不少類似的項(xiàng)目從一開始的能直讀就別轉(zhuǎn)慢慢變成了生產(chǎn)環(huán)境一律先轉(zhuǎn)。這個(gè)轉(zhuǎn)變不是技術(shù)偏好是被運(yùn)維成本教育出來的。下面這張表是這幾年的經(jīng)驗(yàn)匯總參數(shù)不是拍腦袋是實(shí)際折騰過的時(shí)間成本估算。維度GDB 直讀GDAL 擴(kuò)展轉(zhuǎn) GeoPackage 后發(fā)布灌入 PostGIS 后發(fā)布部署復(fù)雜度高需匹配 GDAL 版本與 Java 本地庫低GeoServer 原生支持中需數(shù)據(jù)庫服務(wù)首次配置耗時(shí)半天到兩天一小時(shí)內(nèi)半天讀取性能大圖層中等每次查詢都要穿過 OGR良好優(yōu)秀有真索引數(shù)據(jù)更新直接替換 GDB 目錄替換單文件 gpkg增量 SQL 或重新導(dǎo)入并發(fā)能力一般文件鎖是隱患一般強(qiáng)字段名保留完整完整完整遷移到別的機(jī)器極麻煩環(huán)境要重建復(fù)制一個(gè)文件備份恢復(fù)即可適合場景一次性出圖、臨時(shí)演示中小體量固定數(shù)據(jù)、單機(jī)部署長期運(yùn)行、多圖層、多用戶2.1 為什么直讀路線的隱性成本最高表面上看直讀最干凈——數(shù)據(jù)不需要復(fù)制原件更新了服務(wù)就跟著更新。但實(shí)際落地時(shí)成本集中在三個(gè)地方。第一是版本咬合。GeoServer 的 GDAL 擴(kuò)展會依賴特定大版本的 GDAL比如某個(gè) GeoServer 版本配套的是 GDAL 3.x 某一系列你本機(jī)裝了個(gè)更新的或者更老的Java 加載動態(tài)庫時(shí)直接拋UnsatisfiedLinkError或者加載成功但驅(qū)動列表為空。這個(gè)報(bào)錯(cuò)信息非常不友好經(jīng)常只說找不到 native library不說到底缺哪個(gè)。第二是環(huán)境變量。GDAL 需要GDAL_DATA指向投影定義數(shù)據(jù)目錄PROJ_LIB指向 PROJ 的轉(zhuǎn)換參數(shù)庫。這兩個(gè)變量在命令行里設(shè)好了不代表 GeoServer 的啟動進(jìn)程能繼承到——尤其是 Windows 下用服務(wù)方式啟動、或者用容器啟動的時(shí)候。我見過最典型的情況命令行ogrinfo一切正常GeoServer 里選 GDB 就報(bào)無法識別坐標(biāo)系。第三是文件鎖與并發(fā)。GDB 在讀取時(shí)會持有目錄層面的句柄如果同時(shí)有別的東西比如桌面軟件、同步盤、備份腳本在動這個(gè)目錄GeoServer 的查詢會間歇性失敗而且失敗得很隨機(jī)日志里看不出規(guī)律。2.2 什么情況下直讀仍然值得也不是全盤否定。有這么幾種場景我依然會選直讀。一種是臨時(shí)演示或驗(yàn)收?？蛻衄F(xiàn)場要求服務(wù)必須直連原始數(shù)據(jù)庫不能有中間副本那你只能硬著頭皮上插件。這種場景通常數(shù)據(jù)量不大、并發(fā)很低把環(huán)境配好就行。另一種是數(shù)據(jù)天天變、且變化是整庫替換。轉(zhuǎn)格式每次都要跑一遍全量幾十 GB 的數(shù)據(jù)轉(zhuǎn)換加索引重建要按小時(shí)計(jì)而直讀只需要替換 GDB 目錄再清一下 GeoServer 的緩存。這種高頻全量替換的場景直讀反而省事。還有一種是你已經(jīng)在用 GDAL 生態(tài)做別的事機(jī)器上本來就有一套調(diào)好的 GDAL 環(huán)境插件只是復(fù)用邊際成本接近零。2.3 我為什么在長期項(xiàng)目里優(yōu)先選 PostGIS說個(gè)實(shí)在話只要圖層數(shù)量超過十幾個(gè)、或者有多個(gè)前端同時(shí)在拉 WMS/WFS我就直接上 PostGIS。原因很簡單GeoServer 的很多能力只有在關(guān)系型數(shù)據(jù)源上才是完整的。比如按屬性過濾的查詢下推、空間索引的自動利用、并發(fā)連接池、CQL 過濾的性能、圖層組的聯(lián)合查詢文件型數(shù)據(jù)源要么做不到要么做得很勉強(qiáng)。GeoPackage 是個(gè)很好的折中——單文件、自帶空間索引、支持 UTF-8、字段名不限長度、GeoServer 原生支持不用裝任何插件。中小體量單圖層幾百萬要素以內(nèi)的固定數(shù)據(jù)我基本都轉(zhuǎn)成 GeoPackage。它的短板是寫入并發(fā)差但發(fā)布地圖服務(wù)本來就是讀多寫少問題不大。提示轉(zhuǎn)換不是二選一的終局決定。我常用的做法是先在 GeoPackage 上把樣式、坐標(biāo)系、字段別名全部調(diào)通驗(yàn)證沒問題后再灌進(jìn) PostGIS 做最終上線。中間那一步只是驗(yàn)證GeoPackage 文件本身不用保留這樣既不浪費(fèi)時(shí)間也不會在上線階段才發(fā)現(xiàn)數(shù)據(jù)有問題。3. 環(huán)境搭建GDAL、插件版本、JVM 路徑三者的咬合關(guān)系如果確定走直讀路線這一節(jié)是最容易翻車的地方。我把踩過的順序整理出來先確認(rèn) GDAL 能用再確認(rèn)驅(qū)動存在再裝插件最后配環(huán)境變量并驗(yàn)證。順序錯(cuò)了排查成本翻倍。3.1 版本對齊是第一道坎去 GeoServer 的下載頁找擴(kuò)展包時(shí)注意下載鏈接是按 GeoServer 版本分目錄的。比如你裝的是 2.24 系列就必須下 2.24 目錄下對應(yīng)小版本的 GDAL 擴(kuò)展跨小版本混用有一定概率出問題——不是必然崩但一旦崩了很難定位因?yàn)閳?bào)錯(cuò)信息通常指向不到版本。另一個(gè)對齊點(diǎn)是 GDAL 大版本。擴(kuò)展包內(nèi)部對 GDAL 的調(diào)用接口是有版本要求的裝一個(gè)差了好幾個(gè)大版本的 GDAL癥狀是插件加載成功、數(shù)據(jù)存儲能建、但一預(yù)覽就報(bào)驅(qū)動不支持。我一般的做法是先在目標(biāo)機(jī)器上把 GDAL 裝好并跑通ogrinfo再去看 GeoServer 日志里打印的 GDAL 版本號兩者能對上再往下走。3.2 安裝 GDAL 并確認(rèn) GDB 驅(qū)動在不在Windows 上用現(xiàn)成的安裝包最省事裝完之后把bin目錄加進(jìn)PATH然后開一個(gè)新的命令行窗口驗(yàn)證ogrinfo --version看到版本號說明主程序通了。接下來是關(guān)鍵一步確認(rèn) GDB 驅(qū)動是否被編譯進(jìn)來ogrinfo --formats | grep -i gdbWindows 命令行沒有 grep用ogrinfo --formats | findstr /i gdb正常應(yīng)該能看到類似OpenFileGDB -vector- (ro): ESRI FileGDB這一行ro表示只讀。這對發(fā)布地圖服務(wù)完全夠用——我們只需要讀。如果這一行沒有說明你裝的 GDAL 構(gòu)建里沒帶這個(gè)驅(qū)動換一個(gè)完整構(gòu)建的安裝包或者用 conda 裝一份帶全部驅(qū)動的 GDAL。這一步不通后面所有的配置都是白做。3.3 裝插件、配變量、驗(yàn)證加載把擴(kuò)展包解壓到 GeoServer 的WEB-INF/lib注意是解壓出來的 jar 直接放進(jìn)去不要留一層目錄。然后處理環(huán)境變量。GeoServer 有兩種啟動方式處理方式不一樣。用startup.bat/startup.sh手動啟動的直接改啟動腳本里的JAVA_OPTS追加-Djava.library.path/path/to/gdal/bin同時(shí)在腳本開頭export GDAL_DATA/path/to/gdal/data和export PROJ_LIB/path/to/gdal/share/projWindows 用set。用服務(wù)方式啟動的環(huán)境變量要配到服務(wù)級別或者干脆改注冊表里的服務(wù)環(huán)境。這一步最容易漏因?yàn)槟阍谧约旱慕K端里配好了變量服務(wù)進(jìn)程根本繼承不到。重啟之后去 GeoServer 的關(guān)于頁面或者日志里搜 GDAL能看到版本信息就說明插件活了。這時(shí)候新建數(shù)據(jù)存儲列表里應(yīng)該出現(xiàn) GDAL 相關(guān)條目。填入 GDB 路徑時(shí)注意格式file:///D:/data/road.gdb三個(gè)斜杠、正斜杠不要用 Windows 的反斜杠直接拼。路徑里有中文或者空格時(shí)我建議先用英文路徑測試通過再回頭處理編碼問題——把兩個(gè)變量同時(shí)引入出問題根本分不清是誰的鍋。注意國內(nèi)很多單位的數(shù)據(jù)目錄帶中文名比如基礎(chǔ)地理數(shù)據(jù)/gdb。GDAL 在 Windows 上對非 ASCII 路徑的支持時(shí)好時(shí)壞具體取決于構(gòu)建時(shí)的字符集設(shè)置。穩(wěn)妥做法是把數(shù)據(jù)復(fù)制到一個(gè)純英文路徑下再發(fā)布或者改用轉(zhuǎn)換路線繞開這個(gè)雷。4. 用 GDAL 把 GDB 拆成可發(fā)布的數(shù)據(jù)體檢、轉(zhuǎn)換、修復(fù)走轉(zhuǎn)換路線的話這一節(jié)是核心操作。我把它拆成體檢、轉(zhuǎn)換、修復(fù)三步每一步都有具體的檢查項(xiàng)別跳。4.1 動手之前先做數(shù)據(jù)體檢體檢的目的很明確搞清楚這個(gè) GDB 里到底有什么哪些能用哪些是坑。ogrinfo -so -al D:/data/road.gdb-so是只輸出摘要不輸出要素-al是列出所有圖層。輸出里要重點(diǎn)看四樣?xùn)|西。圖層數(shù)量與名稱。有些 GDB 里幾十個(gè)圖層其中一大半是注記、關(guān)系類、廢棄圖層。把真正要發(fā)布的挑出來別一股腦全轉(zhuǎn)轉(zhuǎn)完在 GeoServer 里一個(gè)個(gè)配樣式能累死人。幾何類型?？词?Point、LineString、Polygon 還是 Multi 版本混用。GDB 允許一個(gè)圖層里混幾何類型但很多目標(biāo)格式和 GeoServer 的渲染器不喜歡混?；煊玫膱D層要么用PROMOTE_TO_MULTI統(tǒng)一成多部件要么拆開。坐標(biāo)系。輸出里L(fēng)ayer SRS WKT那段能看到 EPSG 或者 WKT 定義。這里有個(gè)高頻坑GDB 里記錄的坐標(biāo)系可能是自定義的、帶七參數(shù)的、甚至只是未定義。如果顯示(unknown)就必須手工指定不能指望它自動識別否則發(fā)布出來位置能偏出去幾百米。要素?cái)?shù)量。Feature Count那行。這個(gè)數(shù)字決定你后面要不要分批轉(zhuǎn)、要不要加進(jìn)度條、轉(zhuǎn)換要等多久。幾百萬要素的圖層ogr2ogr跑起來十幾分鐘很正常。4.2 轉(zhuǎn)成 GeoPackage 的完整命令確認(rèn)完就動手。下面這條是我常用的模板參數(shù)含義后面逐個(gè)解釋ogr2ogr -f GPKG D:/out/road.gpkg D:/data/road.gdb ^ -nln road ^ -nlt PROMOTE_TO_MULTI ^ -t_srs EPSG:4490 ^ -lco SPATIAL_INDEXYES ^ -lco FIDfid ^ -progress-f GPKG指定輸出格式。-nln指定輸出圖層名不起這個(gè)名字的話會沿用原名原名如果帶中文或者特殊字符后面在 GeoServer 里做 CQL 過濾會很難寫。-nlt PROMOTE_TO_MULTI把單部件幾何統(tǒng)一提升為多部件避免混類型導(dǎo)致渲染異常。-t_srs做坐標(biāo)系轉(zhuǎn)換不帶這個(gè)參數(shù)就保持原樣——如果你不確定源坐標(biāo)系千萬別亂加這個(gè)參數(shù)轉(zhuǎn)錯(cuò)了比不轉(zhuǎn)更難查。-lco SPATIAL_INDEXYES建空間索引這個(gè)對 GeoServer 的預(yù)覽和范圍查詢性能影響很大一定要開。-progress就是進(jìn)度顯示大圖層必備。如果只想轉(zhuǎn)其中一個(gè)圖層把 GDB 路徑后面加上圖層名ogr2ogr -f GPKG D:/out/road.gpkg D:/data/road.gdb road如果 GDB 里的圖層名有中文或者空格用引號包起來或者先用ogrinfo確認(rèn)準(zhǔn)確寫法。GDAL 對圖層名大小寫不敏感但對空格和特殊字符敏感。4.3 中文亂碼、字段截?cái)?、日期類型的具體處理這三個(gè)問題是 GDB 轉(zhuǎn)換途中最常見的數(shù)據(jù)看著轉(zhuǎn)了、用起來不對。中文亂碼。GeoPackage 內(nèi)部就是 UTF-8轉(zhuǎn)換過程中一般不會亂。真正會亂的是轉(zhuǎn)成 Shapefile 的時(shí)候——Shapefile 需要.cpg文件聲明編碼。如果目標(biāo)格式必須是 Shapefile加上-lco ENCODINGUTF-8并且在 GeoServer 里發(fā)布時(shí)把字符集也設(shè)成 UTF-8兩邊不一致就會出現(xiàn)屬性表里全是問號。我的建議是能不用 Shapefile 就別用字段名 10 字符限制、字段數(shù) 255 限制、日期類型丟失坑太多了。字段名截?cái)?。這個(gè)只在 Shapefile 出現(xiàn)。GDB 里叫ROAD_NAME_FULL的字段轉(zhuǎn)成 Shapefile 會變成ROAD_NAME_兩個(gè)字段如果前 10 個(gè)字符一樣直接沖突報(bào)錯(cuò)。GeoPackage 和 PostGIS 都沒這個(gè)問題這也是我推薦它們的原因之一。日期類型。GDB 里日期字段轉(zhuǎn)出來經(jīng)常變成字符串或者變成一個(gè)奇怪的時(shí)間戳。這會導(dǎo)致 GeoServer 的 WMS 時(shí)間維度功能用不了。轉(zhuǎn)換時(shí)可以用-mapFieldType DateString顯式指定策略或者干脆在轉(zhuǎn)換后用 SQL 在 PostGIS 里改類型。GeoPackage 的日期支持相對好一些但 GeoServer 讀出來的類型仍需要在圖層配置頁確認(rèn)一眼。4.4 幾何有效性修復(fù)與自相交處理GDB 里的面數(shù)據(jù)經(jīng)常有自相交、環(huán)方向錯(cuò)誤、零面積多邊形這些問題。它們在桌面軟件里能顯示但 GeoServer 的渲染器對無效幾何的容忍度低癥狀是某些多邊形消失、或者填充區(qū)域莫名其妙地連成一片。GDAL 3.4 之后ogr2ogr支持-makevalid直接修ogr2ogr -f GPKG D:/out/parcel.gpkg D:/data/parcel.gdb parcel -makevalid -nlt MULTIPOLYGON如果你的 GDAL 版本不支持退化方案是先轉(zhuǎn)出來再用ST_MakeValid在數(shù)據(jù)庫里修或者用 QGIS 的修復(fù)幾何工具批量處理。別指望 GeoServer 幫你兜底它不會。還有一個(gè)不起眼但很致命的點(diǎn)空幾何。有些圖層里混著幾何為 NULL 的記錄轉(zhuǎn)出來之后 GeoServer 在統(tǒng)計(jì)范圍時(shí)可能算出個(gè)無效的包圍盒導(dǎo)致圖層預(yù)覽一片空白你以為是樣式問題其實(shí)是范圍錯(cuò)了。轉(zhuǎn)換時(shí)加-where SHAPE IS NOT NULL過濾掉或者轉(zhuǎn)完之后在目標(biāo)庫里DELETE FROM xxx WHERE geom IS NULL。5. 在 GeoServer 里把圖層真正掛上去數(shù)據(jù)準(zhǔn)備好了接下來是在 GeoServer 里走一遍完整流程。這一段看起來是點(diǎn)點(diǎn)鼠標(biāo)但有幾個(gè)必改項(xiàng)改漏了后面全是麻煩。5.1 新建數(shù)據(jù)存儲的填寫要點(diǎn)進(jìn)數(shù)據(jù)→新建數(shù)據(jù)存儲選 GeoPackage或者 PostGIS。GeoPackage 的路徑填法和 GDB 一樣file:///D:/out/road.gpkg注意格式。PostGIS 則填主機(jī)、端口、庫名、用戶名密碼這些沒什么好說的但有一個(gè)參數(shù)值得調(diào)連接池的min connections和max connections。默認(rèn)值偏保守并發(fā)上來之后會出現(xiàn)等待連接超時(shí)把 max 調(diào)到 20 左右視機(jī)器而定會穩(wěn)很多。工作區(qū)Workspace的選擇不是隨便點(diǎn)。它的作用相當(dāng)于命名空間后面 WMS 請求里的圖層名會是工作區(qū):圖層名。我習(xí)慣按項(xiàng)目或按數(shù)據(jù)主題劃分工作區(qū)別把所有東西堆在默認(rèn)工作區(qū)里后期做權(quán)限控制和圖層組的時(shí)候會感謝自己。5.2 圖層發(fā)布頁面里必須改的幾項(xiàng)點(diǎn)發(fā)布之后進(jìn)入配置頁這一頁信息很多但真正必須確認(rèn)的就幾個(gè)。坐標(biāo)系聲明。Native SRS是數(shù)據(jù)本身的坐標(biāo)系Declared SRS是對外聲明的坐標(biāo)系。這兩個(gè)如果不一致GeoServer 會做動態(tài)投影。絕大多數(shù)情況下應(yīng)該讓兩者一致把 Declared 設(shè)成跟 Native 一樣然后靠 WMS 請求里的SRS參數(shù)控制輸出投影。我曾經(jīng)遇到一個(gè)案例數(shù)據(jù)是投影坐標(biāo)Declared 被誤設(shè)成了經(jīng)緯度結(jié)果前端拿到的圖整體壓縮變形排查了半天才發(fā)現(xiàn)是這個(gè)字段。邊框Bounding Box。點(diǎn)從數(shù)據(jù)中計(jì)算和從原生邊框計(jì)算兩個(gè)按鈕。如果算出來是0,0,-1,-1這種明顯不對的值說明數(shù)據(jù)里有空幾何或者坐標(biāo)系識別錯(cuò)誤回去查數(shù)據(jù)。邊框錯(cuò)了WMS 的BBOX請求會返回空白圖而且不報(bào)錯(cuò)最難排查。屬性勾選。Queryable要勾上否則 WFS 查詢不返回屬性。屬性列表里把不需要對外暴露的字段比如內(nèi)部 ID、敏感備注取消勾選減少傳輸量也順便做了脫敏。5.3 樣式手寫 SLD 還是從桌面軟件導(dǎo)出樣式這一塊我的實(shí)際經(jīng)驗(yàn)是簡單的單色/分級渲染直接在 GeoServer 里用界面生成復(fù)雜的多比例尺、標(biāo)注避讓、圖標(biāo)符號用桌面軟件配好再導(dǎo)出 SLD。界面生成的樣式存在 GeoServer 自己的樣式庫里改起來簡單但表達(dá)力有限。導(dǎo)出 SLD 的好處是所見即所得缺點(diǎn)是導(dǎo)出文件里常常帶一堆冗余定義而且不同版本的導(dǎo)出格式細(xì)節(jié)有差異導(dǎo)入時(shí)報(bào)錯(cuò)的話得手工改。幾個(gè)實(shí)戰(zhàn)要點(diǎn)標(biāo)注Label一定要設(shè)label和font并且配一個(gè)VendorOption控制重疊比如conflictResolutionfalse加spaceAround10否則密集路網(wǎng)的標(biāo)注會糊成一團(tuán)。分級渲染用Intervals比一堆Rule好維護(hù)。圖層如果要素特別多樣式里加VendorOption maxDisplacement之類能明顯降低渲染耗時(shí)。5.4 預(yù)覽驗(yàn)證與切片緩存發(fā)布完之后不要只看圖層預(yù)覽里的 OpenLayers 頁面。那個(gè)頁面會帶上一堆默認(rèn)參數(shù)有時(shí)候恰好繞過了問題。我一般用三步驗(yàn)證OpenLayers 預(yù)覽看整體、GetFeatureInfo請求看屬性對不對、直接拼一個(gè)指定BBOX和SRS的GetMap請求看投影轉(zhuǎn)換有沒有偏。都通過之后再上切片。切片的圖層組方案要和前端的底圖對齊GridSet里的坐標(biāo)系、分辨率層級、瓦片尺寸必須和前端一致不一致就會出現(xiàn)瓦片錯(cuò)位——放大時(shí)圖是清楚的一縮小就整體偏移半屏。緩存建好之后數(shù)據(jù)更新的那天記得清緩存不然前端看到的還是舊圖。6. 踩過的坑六個(gè)真實(shí)翻車現(xiàn)場與排查鏈路這一節(jié)是這篇文章里我最想寫的部分因?yàn)榍懊婺切┎襟E文檔里都能查到下面這些是查不到、只能踩出來的。6.1 插件裝了但驅(qū)動列表是空的癥狀數(shù)據(jù)存儲能建出來選 GDAL 類型路徑填對點(diǎn)保存報(bào)無法創(chuàng)建數(shù)據(jù)存儲。排查鏈路先看 GeoServer 日志搜 GDAL如果只有一行版本號沒有驅(qū)動列表說明本地庫加載了但驅(qū)動初始化失敗。最常見原因是GDAL_DATA沒指向正確目錄GDAL 找不到gcs.csv、proj.db這些數(shù)據(jù)文件。修復(fù)方法是把GDAL_DATA指向 GDAL 安裝目錄下的data新版可能在share/gdalPROJ_LIB指向share/proj重啟進(jìn)程再看日志。還有一個(gè)更隱蔽的原因機(jī)器上裝了多個(gè) GDAL比如 Python 環(huán)境里一份、獨(dú)立安裝一份PATH里排在前面的那個(gè)版本和插件要求的不一致。用where gdalinfo看一眼到底用的哪一份把不對的從PATH里挪走。6.2 圖層預(yù)覽一片空白日志沒有任何報(bào)錯(cuò)這是最消耗耐心的一類問題。排查順序我固定成四步。第一步看圖層配置頁的邊框是不是有效值。是0,0,-1,-1就說明數(shù)據(jù)范圍沒算出來回去查幾何和坐標(biāo)系。第二步用ogrinfo -al -geomSUMMARY打開源數(shù)據(jù)看第一條要素的坐標(biāo)大概是多少。如果坐標(biāo)是幾百、幾千量級說明是投影坐標(biāo)如果是 100 多、30 多說明是經(jīng)緯度。兩種情況下圖層配置里的 Native SRS 必須對得上。第三步手工拼 GetMap 請求把SRS、BBOX、WIDTH、HEIGHT全部顯式寫上看返回的 PNG 是不是全透明。第四步如果前三步都對但還是空檢查樣式。用一個(gè)最簡單的PolygonSymbolizer純紅色測試排除樣式表達(dá)式寫錯(cuò)導(dǎo)致的渲染失敗。6.3 大字段和 BLOB 讓渲染慢到無法接受GDB 里經(jīng)常帶照片、附件、超長備注這類字段。轉(zhuǎn)出來之后這些字段還在GeoServer 在生成要素時(shí)會把它們一起讀出來即使樣式根本用不到。一個(gè)幾萬要素的圖層帶 BLOB 字段單次 GetMap 能慢到十幾秒。解決辦法很直接轉(zhuǎn)換時(shí)就不帶這些字段。ogr2ogr支持-selectogr2ogr -f GPKG D:/out/poi.gpkg D:/data/poi.gdb poi -select name,type,lng,lat-select里只寫要保留的字段其他一律不轉(zhuǎn)。如果字段已經(jīng)轉(zhuǎn)出來了在 PostGIS 里ALTER TABLE ... DROP COLUMN更快。這一步做完同一個(gè)圖層的出圖時(shí)間能從十幾秒降到一秒以內(nèi)。6.4 WMS 出圖中文標(biāo)注變成方塊這個(gè)問題的根源是字體。GeoServer 渲染標(biāo)注時(shí)用的是服務(wù)端字體如果 SLD 里指定的字體在服務(wù)器上不存在就會 fallback 到一個(gè)沒有中文字形的字體渲染出來全是方塊或者豆腐塊。修復(fù)分兩步先確認(rèn)服務(wù)器上裝了中文字體Linux 下把字體文件放進(jìn)/usr/share/fonts再fc-cache -fv然后在 SLD 里把font-family設(shè)成一個(gè)確定存在的字體名。GeoServer 后臺有個(gè)字體列表頁面能看到當(dāng)前能用的字體SLD 里寫的名字必須在這個(gè)列表里。我一般會寫一個(gè)字體棧比如先寫主字體再寫 fallback但 GeoServer 對字體棧的支持不如瀏覽器穩(wěn)定實(shí)測還是指定單一存在的字體最可靠。6.5 時(shí)間字段變成字符串時(shí)間維度功能失效前面提過日期類型轉(zhuǎn)換會丟。這個(gè)問題在發(fā)布帶時(shí)間維度的服務(wù)時(shí)會集中爆發(fā)——GeoServer 的 WMS 時(shí)間維度要求字段是java.sql.Timestamp或者Date如果是字符串配置頁面里那個(gè)時(shí)間選項(xiàng)卡根本不會出現(xiàn)。修復(fù)方式取決于目標(biāo)庫。PostGIS 里可以直接ALTER TABLE t ALTER COLUMN dt TYPE timestamp USING dt::timestamp前提是字符串格式規(guī)范。GeoPackage 里類型改起來麻煩通常的做法是轉(zhuǎn)換時(shí)就用-mapFieldType強(qiáng)制指定或者在桌面軟件里先規(guī)范格式。我遇到過一次數(shù)據(jù)里的日期是2023/5/1這種非標(biāo)準(zhǔn)寫法轉(zhuǎn)出來之后解析失敗全變 NULL最后是用 SQL 逐條清洗的。6.6 面圖層自相交導(dǎo)致部分要素不渲染前面提到過-makevalid這里說一個(gè)更細(xì)的坑有些自相交在轉(zhuǎn)換時(shí)被修成了空幾何。修完之后要素?cái)?shù)量沒變但幾何是空的GeoServer 渲染時(shí)直接跳過看起來就像是某些地塊憑空消失了。排查方法是轉(zhuǎn)完之后統(tǒng)計(jì)空幾何數(shù)量SELECT count(*) FROM parcel WHERE geom IS NULL OR ST_IsEmpty(geom);不為零就說明有要素被修沒了。處理方式有兩種要么回頭在源數(shù)據(jù)里手工修這幾個(gè)要素通常數(shù)量不多要么接受丟失但記錄下來。我一般選前者因?yàn)槊鏀?shù)據(jù)丟一個(gè)業(yè)務(wù)上可能就是一塊地沒了。7. 服務(wù)上線之后的三件運(yùn)維事發(fā)布成功只是開始真正讓人熬夜的是上線之后。這三件事我在每個(gè)項(xiàng)目里都會提前處理。7.1 連接池與 JVM 內(nèi)存GeoServer 默認(rèn)的 JVM 堆內(nèi)存偏小幾個(gè)大圖層一起渲染就容易OutOfMemoryError。啟動腳本里把-Xmx調(diào)大具體值看機(jī)器內(nèi)存一般給到物理內(nèi)存的一半以內(nèi)比較穩(wěn)。但要注意堆開太大Full GC 的時(shí)間也會變長反而造成請求卡頓所以不是越大越好。連接池方面文件型數(shù)據(jù)源GeoPackage沒有連接池概念但 PostGIS 有。max connections別設(shè)太高超過數(shù)據(jù)庫端的連接上限會直接拒絕。這個(gè)值我一般按前端并發(fā)數(shù) × 1.5估然后壓測驗(yàn)證。另外記得開validate connections數(shù)據(jù)庫重啟之后連接池能自動恢復(fù)不然會出現(xiàn)服務(wù)活著但所有查詢都失敗的情況。7.2 切片方案與緩存失效切片是性能和體驗(yàn)的分水嶺。有緩存和沒緩存同一個(gè)圖層的首屏?xí)r間差一個(gè)數(shù)量級。但切片有個(gè)前提圖層組、坐標(biāo)系、分辨率層級、瓦片尺寸必須和前端底圖完全一致。差一點(diǎn)都不行表現(xiàn)出來就是偏移或者縮放層級錯(cuò)亂。緩存失效策略我通常配成兩種按圖層手動清以及按區(qū)域清。數(shù)據(jù)更新頻率低的更新完手動清一次就行更新頻繁的用 GeoServer 的 REST 接口在數(shù)據(jù)導(dǎo)入流程結(jié)束后自動觸發(fā)清理比人肉操作可靠。注意清緩存的時(shí)候別忘了 GeoServer 還有一層要素緩存配置頁里的Queryable附近有個(gè)緩存設(shè)置。圖層元數(shù)據(jù)緩存不清改完數(shù)據(jù)可能還是舊的范圍和要素?cái)?shù)看著像數(shù)據(jù)沒更新其實(shí)是緩存騙了你。7.3 數(shù)據(jù)更新的落地策略轉(zhuǎn)換路線的最大痛點(diǎn)是數(shù)據(jù)不是實(shí)時(shí)的。所以必須提前設(shè)計(jì)更新流程而不是等業(yè)務(wù)方問為什么昨天的圖還沒變才想。我的常規(guī)做法是保留一套腳本ogr2ogr轉(zhuǎn)換帶-append參數(shù)做增量追加前提是源數(shù)據(jù)有穩(wěn)定主鍵或者整表DROP后重建數(shù)據(jù)量不大時(shí)更簡單可靠。腳本跑完自動調(diào) GeoServer 的 REST 接口刷新數(shù)據(jù)存儲、清圖層緩存。整套流程串起來更新就是從人工操作半小時(shí)變成跑個(gè)任務(wù)等幾分鐘。如果數(shù)據(jù)源是別人提供的、更新時(shí)機(jī)不可控那就得在前端或者圖層配置里給個(gè)數(shù)據(jù)截止時(shí)間的說明至少讓使用者心里有數(shù)。這個(gè)細(xì)節(jié)看著不起眼但能省掉大量你們數(shù)據(jù)不對的扯皮。最后說一句個(gè)人體會GDB 轉(zhuǎn) GeoServer 這件事技術(shù)難度其實(shí)不高難的是把數(shù)據(jù)本身的問題摸清楚。我做過這么多類似的項(xiàng)目真正卡住人的從來不是插件裝不上而是坐標(biāo)系是自定義的、幾何是壞的、字段是重復(fù)的、編碼是亂的。所以每次開工我都會花半小時(shí)把ogrinfo的輸出從頭到尾讀一遍把可疑的地方記下來先處理掉。這半小時(shí)往往能把后面三天的返工省下來。