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