1. 先把 .gmt 文件当成文本 段来看只要还在跟 GMTGeneric Mapping Tools那套脚本打交道.gmt这个后缀迟早会出现在你面前。我最近一次碰到它是接手一个跑了七八年的出图流程前处理那一段用 Python 写中间产出一批.gmt矢量文件后面由一堆老的 GMT 脚本负责投影和绘图。整套流程没人敢动但上游数据源换了一次字段结构变了我必须用 GDAL/OGR GMT 矢量驱动GMT ASCII Vectors把这几百个文件读进来、改属性、再原样写回去且不能破坏旧脚本能读的格式。这篇东西就是把那一轮折腾的完整记录摊开GMT ASCII Vectors这个 OGR 驱动的文件格式到底长什么样、读写操作怎么下手、源码层面它是怎么实现一个要素游标的以及踩过的那些会让人 debug 一整天的坑。哪怕你只是想把一份.gmt转成 GeoPackage 看看里面是什么或者反过来——把现代矢量数据导出成老脚本能吃的格式——都能直接照着用。不需要你懂 C但源码那几节会把驱动的内部状态机讲清楚因为很多打开成功却读不到要素的问题答案只在那里。另外先把期望值拉正.gmt不是 OGR 生态里的活跃格式它更像一座桥用来连接现代 GIS 工具链和老旧 GMT 出图脚本两套世界。认清这一点后面所有的取舍判断都会顺很多。1.1 这个驱动解决的是哪种交接问题把地理数据写进文本文件的方式很多GeoJSON 是主流WKT 也能用但 GMT 走的是另一条简洁得过分的路一个文件里堆若干段每段头部是一行以#开头的说明后面跟着若干行纯数字坐标。这种设计在绘图脚本里极方便——脚本只要跳过#开头的行把剩下两列当经纬度喂给绘图命令就完事了。代价是它几乎不携带元信息没有要素 ID、没有字段定义、没有坐标系描述几何类型也只是靠一个标记字符串表示。所以 OGR GMT 驱动的核心工作是给这套极简文本套上一层 OGR 的数据模型外壳。具体做三件事把每个.gmt文件识别成一张表图层把段头里的标记解析成几何类型和包络框把数据行的坐标还原成OGRGeometry。反向则是把OGRFeature拆回文本行。听着简单但真正的复杂度全在边界情况上——空段、混合几何类型、多环面、带 Z 值的点、只有一列的数据行。我遇到那个项目里的文件就是这样大部分是线但有几个文件里混着点段全在一个.gmt里。这种一个文件一种几何类型的约定一旦被打破读取结果就很考验驱动的容错设计。1.2 OGR 视角下的结构一个文件一堆段在 OGR 的模型里一个.gmt文件打开后是一张表。表里每一行就是一个要素。但文件物理上是段组织的一段可能对应一个要素也可能对应一个多部件要素的某个部件。这个映射关系是理解整个驱动最关键的认知点。举个直观的对比Shapefile 里一个.shp是明确的一条记录一个要素记录长度写在文件头里边界清清楚楚。.gmt没有长度前缀也没有索引解析器只能一行一行往下读靠遇到新的#头记录或者遇到独立的分段符来判断上一段结束了。这就是为什么这个驱动内部的读取逻辑是一个典型的流式状态机而不是随机访问——它天然没法随机访问。按常见实践补充一点正因为没有索引GetFeatureCount()这类操作在较老的实现里可能返回-1未知得靠GetNextFeature逐条遍历才能知道总数。写脚本时别假设GetFeatureCount()一定有准数。1.3 能力边界对照表上手前先看这张表比翻文档快能力项支持情况说明读取点支持每行一个点读取线支持一段一条线支持拆环读取面支持依赖闭合环 分段符读取多点/多线/多面支持段头类型标记为 MULTI 系列时图层字段极其有限通常只能承载一个属性字段别指望多列写坐标系不支持读写都不处理 SRS这是硬伤空间索引无属性过滤和空间过滤都是全表扫描创建文件支持-f GMT随机更新不支持要改内容只能整体重写事务不支持无编码纯 ASCII 假定非 ASCII 属性容易出问题把这些当成一份使用前须知能省掉你至少两轮试错。特别是 SRS 那一行我见过太多人往里面塞投影信息写完发现文件里根本没有还以为是工具坏了。2. 格式拆到底头记录、坐标行与分段符我习惯把这种文本格式拆到能手写出一个合法文件的程度再动手写代码。因为一旦你能手写任何读取异常都能用二分法定位到底是文件本身不合法还是驱动理解得不对。2.1 头记录里的 字段逐个说头记录就是一行以#开头的文本后面跟着若干以开头的标记块用空格隔开。这些标记块是格式的全部元信息。常见的几个V格式版本最常见的是VGMT1.0。这一项主要是给读取方一个这是新式 GMT 矢量文件的信号。G几何类型标记取值一般是 OGR 几何类型的名字比如POINT、LINESTRING、POLYGON以及它们对应的MULTI版本。这个字段决定了驱动构造什么样的OGRGeometry。R区域包络格式是xmin/xmax/ymin/ymax。注意顺序是经度最小/经度最大/纬度最小/纬度最大跟 OGR 的Envelope的排列顺序xmin/ymin/xmax/ymax不一致。这个坑我在两个项目里都踩过读起来没报错但算出来的范围整个错位。N属性字段名。驱动通常只维护一个属性字段字段名就写在这里。T属性字段类型比如字符串、整型、浮点。J投影参数形式类似e-71.5/46.5/3。这一项很关键——它看起来像坐标系信息但 OGR 驱动基本不解析它读进来GetSpatialRef()还是空。别指望靠它恢复 SRS。注意不同工具生成的头记录里字段的出现顺序和完整性差别很大。有的只写V和G有的连V都没有。读取端的容错设计是能认的认认不了的忽略缺G时按数据行内容兜底推断。这也是我建议的一个习惯手头拿到一个来源不明的.gmt先head -3看一下头记录长什么样比直接扔给 ogrinfo 更省时间。头记录里少一个G后面所有几何类型的判断都可能跑偏。2.2 坐标行与 分段符数据行就是一行若干列空白分隔的数字。绝大多数情况是两列x、y也可能三列x、y、z。列与列之间用空格或者制表符都行行尾的空白会被忽略。分段符是一个单独的字符起始的行后面可以跟文字说明驱动通常只看第一个字符。它在两种场景下出现第一种是多部件要素。比如一个多面要素外环一段、内环一段中间用隔开。驱动读到就知道上一段几何到此结束下面开始的是同一个多部件要素的下一个部件。第二种是一个文件里多个独立要素共用同一份头记录。有些工具为了省字节只写一次头后面用分隔若干个独立要素。这种情况下驱动的处理就依赖于它把解释成部件分隔还是要素分隔这部分行为在不同版本里不完全一致实测下来建议如果你要生成.gmt给别的系统吃别图省事共用头记录每个要素老老实实写一份完整头。我吃过一次亏。为了压缩文件体积我把 4 万个点全部塞进一个头记录下面用分隔。结果我们自己的 OGR 读出来是对的但客户那边的老脚本读出来只画了第一个点。查了半天是人家的解析器把当成整个数据块结束。这种双方都觉得自己没错的问题最后只能靠统一写法解决。2.3 属性是怎么塞进去的这是这个格式最别扭的部分。文本格式本来就没给属性留位置驱动只能用一种约定的方式承载头记录里用N声明一个字段名、T声明类型数据行的最后一列放属性值。结论很明确一个图层基本只有一个字段可用。如果你把一个带十几个字段的 GeoPackage 转成 GMT最后大概率只剩一个字段其余全丢。这个行为不是 bug是格式本身的容积决定的。实际项目里我的处理方式是这样需要多字段信息时把关键字段拼成一个分隔符连接的字符串塞进那唯一一个字段里回头读的时候再按分隔符拆开。虽然丑但省事且不丢信息。至于中文纯 ASCII 假定是这套格式的底色实测中非 ASCII 字符能不能完整往返取决于文件编码、驱动版本和系统 locale 三者建议直接在源头把中文转成拼音或者 ID别赌。2.4 三份手写样例三份最小的可读样例点、线、面各一份。手敲一遍你对这个格式的理解会比读十页文档扎实。# VGMT1.0 GPOINT R116.0/116.5/39.5/40.0 Nname Tstring 116.10 39.60 A1 116.20 39.70 A2 116.30 39.80 A3三个点每行最后一列是那个唯一属性的值。# VGMT1.0 GLINESTRING R116.0/116.5/39.5/40.0 Nname Tstring 116.10 39.60 116.20 39.70 116.30 39.80 T1注意线的属性写在最后一行行尾不是写在头记录里。这个细节在手工造测试数据时特别容易搞错。# VGMT1.0 GPOLYGON R116.0/116.5/39.5/40.0 Nname Tstring 116.10 39.60 116.30 39.60 116.30 39.80 116.10 39.80 116.10 39.60 P1 116.15 39.65 116.20 39.65 116.20 39.70 116.15 39.70 116.15 39.65带内环的面环之间用隔开。首尾点要闭合否则部分驱动版本会当成未闭合环处理读出来可能变成线。3. 读写实操从 ogrinfo 到 Python命令行是探索阶段最快的工具。我一般先用ogrinfo摸清楚驱动怎么理解这个文件再决定用ogr2ogr还是写脚本。3.1 三行命令摸清一个陌生文件第一步永远是把驱动的能力打出来确认你装的环境里真的有这个驱动ogrinfo --format GMT输出里能看到驱动支持的数据集扩展名、是否支持创建、支持哪些几何类型。如果这条命令没输出说明你的 GDAL 构建里把这一块裁掉了后面的操作都不用试了。第二步只读元信息不碰数据ogrinfo -ro -al -so sample.gmt-so是 summary only此时你会看到图层名、几何类型、要素数可能是-1、字段列表、范围。这一条命令就能验证三件事几何类型对不对、字段有没有丢、包络框合不合理。范围那项尤其好用——如果范围明显偏了一个量级多半是R的排列顺序被误解或者数据里混进了比例尺之类的奇怪数值。第三步抽几条看实际值ogrinfo -ro -al -limit 3 sample.gmt到这里如果结果不对就基本可以断定是文件自身的问题而不是你的代码问题。3.2 ogr2ogr 的双向转换与 -lco转出GMT 转现代格式最省心ogr2ogr -f GPKG out.gpkg sample.gmt -nln track转回现代格式转 GMT要注意两点ogr2ogr -f GMT out.gmt source.gpkg -nln track -select name一是必须显式写-f GMT靠扩展名猜是不可靠的。二是强烈建议用-select只保留一个字段。既然格式只装得下一个字段那就主动选那个最重要的别让驱动随机挑一个——尤其当源表第一个字段是内部 ID 的时候随机挑的结果就是把一堆无意义的数字写进了属性。批量转换可以用 shell 循环for f in input/*.gmt; do base$(basename $f .gmt) ogr2ogr -f GPKG output/${base}.gpkg $f -nln $base done日志留一份很重要因为批量跑完你很难回忆哪个文件当时报了 warning。加-progress能看到进度快速定位卡在哪个文件。提示ogr2ogr转换 GMT 时方向性错误不会报错只会静默生成一个空图层或者属性全空的结果。所以流水线里一定要加一步校验转换后ogrinfo -so检查要素数是否大于零、字段是否非空。3.3 Python 端读写用osgeo.ogr直接操作控制力最强from osgeo import ogr drv ogr.GetDriverByName(GMT) if drv is None: raise RuntimeError(GMT driver not available) ds drv.Open(sample.gmt, 0) # 0 read only lyr ds.GetLayer(0) print(geom:, ogr.GeometryTypeToName(lyr.GetGeomType())) print(fields:, [lyr.GetLayerDefn().GetFieldDefn(i).GetName() for i in range(lyr.GetLayerDefn().GetFieldCount())]) for feat in lyr: g feat.GetGeometryRef() env g.GetEnvelope() # (xmin, xmax, ymin, ymax) print(feat.GetFID(), g.GetGeometryName(), env)GetEnvelope()返回的顺序和R一致都是xmin, xmax, ymin, ymax这点倒是挺贴心但它跟OGRGeometry.GetEnvelope()在别的地方的用法又有差异写代码时最好显式拆包成变量名别靠位置记。写出from osgeo import ogr, osr drv ogr.GetDriverByName(GMT) ds drv.CreateDataSource(out.gmt) lyr ds.CreateLayer(track, geom_typeogr.wkbLineString, options[]) fd ogr.FieldDefn(name, ogr.OFTString) lyr.CreateField(fd) feat ogr.Feature(lyr.GetLayerDefn()) feat.SetField(name, L1) line ogr.Geometry(ogr.wkbLineString) line.AddPoint_2D(116.10, 39.60) line.AddPoint_2D(116.20, 39.70) feat.SetGeometry(line) lyr.CreateFeature(feat) feat None ds None # 必须显式释放否则缓冲没刷盘最后那两行 None是老生常谈但真的会坑人。GDAL 的 Python 绑定靠引用计数触发 flush脚本跑到一半崩溃文件就是半个。我见过太多写出来的文件只有第一条要素的案例追根溯源都是没释放数据源对象。3.4 批量脚本与目录级处理需要处理的文件一多最麻烦的其实不是转换本身而是哪些文件读失败、失败在哪里。我的做法是把读取包成函数只返回结构化结果把异常都吃掉转成状态def probe(path): from osgeo import ogr drv ogr.GetDriverByName(GMT) ds drv.Open(str(path), 0) if ds is None: return {file: path.name, ok: False, reason: open_failed} lyr ds.GetLayer(0) n lyr.GetFeatureCount() if n 0: n sum(1 for _ in lyr) lyr.ResetReading() return {file: path.name, ok: n 0, reason: if n 0 else empty_layer, count: n, geom: ogr.GeometryTypeToName(lyr.GetGeomType())}GetFeatureCount()返回负数时用遍历兜底这一段很关键不然你会把计数未知误判成是负数所以有问题。较新的 GDAL 版本里把一个目录路径传给驱动有时能展开成多图层每个.gmt一个但这一行为随版本变化我不敢把它写进生产脚本。稳妥做法还是自己遍历目录、逐文件打开。4. 源码实现从注册到游标前面说了这个驱动本质上是文本流的 OGR 适配层。看懂它的实现你能省掉大量试错尤其是那些看着没毛病但就是读不出来的问题。4.1 驱动注册与 Open 的分流OGR 驱动的入口是注册函数注册时把元数据和回调函数指针挂上去。简化后的骨架大致是这样void RegisterOGRGMT() { if (GDALGetDriverByName(GMT) ! nullptr) return; GDALDriver *poDriver new OGRGMTDriver(); poDriver-SetDescription(GMT); poDriver-SetMetadataItem(GDAL_DCAP_VECTOR, YES); poDriver-SetMetadataItem(GDAL_DCAP_CREATE, YES); poDriver-SetMetadataItem(GDAL_DCAP_CREATECOPY, YES); poDriver-SetMetadataItem(GDAL_DMD_EXTENSIONS, gmt); poDriver-pfnOpen OGRGMTDriverOpen; poDriver-pfnCreate OGRGMTDriverCreate; poDriver-pfnDelete OGRGMTDriverDelete; GetGDALDriverManager()-RegisterDriver(poDriver); }注意GDAL_DMD_EXTENSIONS只登记了gmt。这意味着靠扩展名自动识别是可行的但如果你手上的文件后缀是.txt或者别的自动识别就会失败Open会返回空。这类打开失败的问题八成不是文件坏了而是扩展名对不上——解决办法是强制指定驱动而不是加后缀。在 Python 里就是先GetDriverByName(GMT)再调Open绕开自动识别。OGRGMTDriverOpen里做的事情很少先按扩展名和文件头做一次快速判断然后构造OGRGMTDataSource让它去真正打开。4.2 数据源与图层的构建数据源这一层主要负责一个文件 → 一张表的映射。它的Open里通常做这几件事检查路径存在、判断是普通文件还是目录、如果是目录则扫描其中的.gmt并逐个子图层打开。图层对象建立时会先做一次探测性读取打开文件流读到第一行#头记录解析出几何类型、字段名、字段类型把OGRFeatureDefn建好。这一步决定了后面GetLayerDefn()返回什么。这里有个很实际的现象如果文件头记录里没有G几何类型就只能等读到第一条数据才能确定。这时候GetLayerDefn()在被调用时可能返回wkbUnknown。我在写通用转换工具时吃过这个亏——先读GetGeomType()再决定处理逻辑结果拿到wkbUnknown直接走了异常分支但文件其实是好的。稳妥的做法是先调一次GetNextFeature()再ResetReading()然后读几何类型。用一条记录换一个确定的类型这笔买卖很划算。4.3 读路径的状态机这是整个驱动最值得看的地方。GetNextFeature()本质上是个循环推进的状态机逻辑简化下来是这样OGRFeature *OGRGMTLayer::GetNextFeature() { while (true) { const char *pszLine ReadLine(); if (pszLine nullptr) { // EOF把累积中的几何收尾吐出去 return EmitPendingFeature(); } if (pszLine[0] #) { ParseHeader(pszLine); // 更新类型、字段、范围 continue; } if (pszLine[0] ) { // 段结束结束当前环/当前部件 CloseCurrentRingOrPart(); continue; } if (IsBlank(pszLine)) continue; AppendVertex(pszLine); // 追加一个坐标点 } }真实实现当然更啰嗦但结构就是这样。看懂这段很多现象都能自己解释为什么只读到第一条EOF 分支里EmitPendingFeature之后没有重置状态或者上层没再次调用。为什么面读成了线分段符没被正确处理闭环逻辑没触发。为什么计数是 -1整个流程是纯流式的不预先扫描文件所以数量只能边读边数。还有空间过滤和属性过滤。标准的 OGR 驱动在GetNextFeature里会应用m_poFilterGeom和m_poAttrQuery。但对这个驱动大概率是读完再过滤因为文件里没有索引可用。这意味着对一个 50 万点的文件做一次范围查询耗时和全表扫描一样。这个认知很重要能帮你避免写出 O(n²) 的批处理脚本。4.4 写路径与头记录生成写入的关键在于头记录只写一次。驱动内部会维护一个m_bHeaderWritten之类的标志OGRErr OGRGMTLayer::ICreateFeature(OGRFeature *poFeature) { if (!m_bHeaderWritten) { CPLString osHeader # VGMT1.0 G; osHeader OGRGeometryTypeToName(GetLayerDefn()-GetGeomType()); // R 由几何包络填入顺序固定 xmin/xmax/ymin/ymax // N/T 由第一个字段的定义填入 WriteLine(osHeader); m_bHeaderWritten true; } WriteGeometryAndAttributes(poFeature); return OGRERR_NONE; }这里有个隐性的坑R是在写第一条要素时用那条要素的包络填的而不是整个图层的包络。也就是说后写入的要素如果超出了第一条的范围头记录里的R就是错的。有些下游工具会拿R做初始视窗设置结果图画出来只显示了一小部分。我在项目里的处理是生成.gmt时先自己算一遍整体包络一条条写完之后再回头把第一行重写掉。文件不大时直接内存里拼好一次性写最干净。4.5 编译与断点调试需要改驱动行为时才走到这一步。常规做法是构建 GDAL 时打开调试符号然后用--debug on看驱动层面的日志ogrinfo --debug on -al sample.gmt 21 | head -50日志里会打出驱动被尝试加载、打开、失败的顺序。如果 GMT 驱动根本没出现在尝试列表里那说明是加载阶段的问题跟你文件内容无关。想直接断点可以在GetNextFeature的 EOF 分支和分支各下一个断点跑一个三要素的小文件单步走一遍。走完之后你会对什么时候吐要素有完全不一样的理解比读代码快得多。我在排查一个多面只读出第一个环的问题时就是这么干的最后发现是处理完之后没把当前环追加进多面容器。5. 常见问题与排查实录这一节全部来自真实排查记录按出现频率从高到低排。5.1 打开成功但要素为零最常见的场景路径没错、文件不空、ogrinfo也不报错就是 0 条要素。三个可能。一是头记录之后的东西全被当成注释。有些工具生成的头记录会连续写好几行#开头的说明文字如果驱动把第一个#之后的#行当成新的段头并重置状态前面累积的坐标就没了。二是数据行前面有前导空格被当成空行跳过了。三是字段分隔符不是空白而是逗号。排查顺序建议固定成这样先head -5看前五行再grep -c ^#数头记录行数最后awk {print NF} | sort -u看每行的列数分布。列数出现预料之外的取值比如大部分是 2但有几行是 5基本就能锁定问题。5.2 面被读成线 / 环被连错面读成线几乎只有一个原因环没闭合或者的位置不对。这个格式没有这个环是外环还是内环的显式标记全靠顺序和闭合性推断。我遇到过一个更隐蔽的情况面文件里最后一个点跟第一个点数值上相同但一个是116.10一个是116.100。字符串比较不相等浮点比较相等不同版本的闭合判断用不同的比较方式结果就不一致。解决办法是在生成端统一格式化用固定精度输出。5.3 属性丢字段、中文乱码字段丢失是格式容量决定的不是 bug。源数据有 12 个字段写出后只剩 1 个正确行为。中文乱码则要看两边。如果文件里是 UTF-8 而读取端按 latin-1 解就会变成一堆问号或者乱码方块。这类问题不要试图在 OGR 层面修源头转成 ASCII 更省心。我现在的标准做法是属性值只放编号P001、T017这种编号到名称的映射单独维护一张表。5.4 大文件与内存.gmt没有索引所有操作都是全表扫描。10 万行以内的文件随便折腾上到百万级就要注意了。几个实测有效的做法读取时用流式遍历for feat in lyr不要先GetFeatureCount()再切片过滤条件尽量在读取之后自己筛别指望驱动帮你优化写大文件时按块提交别在内存里攒几万个OGRFeature对象那个内存占用比你想象的高得多。5.5 问题速查表现象最可能的原因处理办法打开返回空扩展名不是.gmt显式GetDriverByName(GMT)后 Open要素数为 0头记录之后全被当注释检查是否连续多行#只读到第一条数据源未释放 / 未 ResetReading显式ds None面读成线环未闭合或位置错误校验首尾点严格相等范围明显错位R顺序是 xmin/xmax/ymin/ymax手工核对头记录坐标系为空格式本身不承载 SRS转换后单独补 SRS字段只剩一个格式容量限制用-select主动选中文变乱码编码不匹配源头转 ASCII 或编号写入后文件不完整未 flush显式释放数据集对象大批量转换很慢无索引全表扫描分片处理避免重复打开6. 什么时候别用它边界与取舍写到这儿得说点反向的话——这个驱动不值得被当成主力格式用。它的价值在桥不在仓。6.1 与主流矢量格式的取舍如果链路两头都是现代工具那就别引入.gmt。GeoPackage 有索引、有事务、有完整字段、有 SRS任何一维度都碾压。只有在一种情况下.gmt是正确答案下游有现成的脚本或工具只认这个格式且改动成本高于适配成本。我做过一次评估把这个格式和几条常见路径摆在一起比过维度GMT ASCII VectorsGeoPackageGeoJSON字段容量1 个无限制无限制坐标系不承载完整可选可读性人眼可读二进制人眼可读体积小中大随机访问不支持支持不支持老脚本兼容极好差一般结论很清楚它的唯一优势是老工具能直接吃和人眼能看能 diff。所以我的用法固定为——.gmt只出现在系统边界进入内部立刻转成 GeoPackage出去时再从 GeoPackage 导出。中间层永远不用它。6.2 版本兼容的坑同一份.gmt不同 GDAL 版本读出来的结果可能不一样。我实测过的主要差异点有两个字段名从N解析时的边界处理以及被当作部件分隔还是要素分隔。应对办法只有一个在 CI 里放一份固定的小样例每次升级 GDAL 版本都跑一遍回归比对要素数、几何类型、包络框、属性值四项。这个成本极低但能挡住绝大多数静默错误。样例文件不需要大三个点、一条线、一个带洞的面就够了。6.3 回归测试怎么写我的写法是用ogrinfo -so的输出做快照比对简单粗暴但有效ogrinfo -ro -al -so fixtures/sample.gmt actual.txt diff -u fixtures/expected.txt actual.txtexpected.txt里把要素数、几何类型、范围、字段列表都记下来。版本升级导致输出变化时diff 会直接告诉你哪一项变了比人肉检查快十倍。如果不想依赖命令行用 Python 写断言也可以def test_gmt_roundtrip(tmp_path): from osgeo import ogr src fixtures/sample.gmt drv ogr.GetDriverByName(GMT) ds drv.Open(src, 0) lyr ds.GetLayer(0) assert ogr.GeometryTypeToName(lyr.GetGeomType()) Line String n sum(1 for _ in lyr) assert n 1一次真实的数据丢失事故让我记住了这个格式一套出图脚本的上游数据换了来源新数据的包络顺序不符合R的约定生成的图整片偏移。排查花了整整两天最后发现是三个字符的顺序问题。从那以后我在所有涉及这个格式的转换节点上都加了范围校验——转出前后各算一次包络差值超过阈值就直接失败不让错误数据流到下游。这种笨办法其实最划算它把一次两天的排查变成了一次两秒的失败。另外补一个小技巧手工造测试数据时别用真实业务数据裁剪直接手写一个最小样例。业务数据里总有些边界值会干扰判断最小样例能让每次失败的原因都指向唯一。我现在维护的那份 fixture 只有 12 行涵盖点、线、带洞面、多部件和空段五种情况两年来抓出过三次驱动行为变化带来的回归。这个投入产出比在任何项目里都算高的。
1. 先把 .gmt 文件当成文本 段来看只要还在跟 GMTGeneric Mapping Tools那套脚本打交道.gmt这个后缀迟早会出现在你面前。我最近一次碰到它是接手一个跑了七八年的出图流程前处理那一段用 Python 写中间产出一批.gmt矢量文件后面由一堆老的 GMT 脚本负责投影和绘图。整套流程没人敢动但上游数据源换了一次字段结构变了我必须用 GDAL/OGR GMT 矢量驱动GMT ASCII Vectors把这几百个文件读进来、改属性、再原样写回去且不能破坏旧脚本能读的格式。这篇东西就是把那一轮折腾的完整记录摊开GMT ASCII Vectors这个 OGR 驱动的文件格式到底长什么样、读写操作怎么下手、源码层面它是怎么实现一个要素游标的以及踩过的那些会让人 debug 一整天的坑。哪怕你只是想把一份.gmt转成 GeoPackage 看看里面是什么或者反过来——把现代矢量数据导出成老脚本能吃的格式——都能直接照着用。不需要你懂 C但源码那几节会把驱动的内部状态机讲清楚因为很多打开成功却读不到要素的问题答案只在那里。另外先把期望值拉正.gmt不是 OGR 生态里的活跃格式它更像一座桥用来连接现代 GIS 工具链和老旧 GMT 出图脚本两套世界。认清这一点后面所有的取舍判断都会顺很多。1.1 这个驱动解决的是哪种交接问题把地理数据写进文本文件的方式很多GeoJSON 是主流WKT 也能用但 GMT 走的是另一条简洁得过分的路一个文件里堆若干段每段头部是一行以#开头的说明后面跟着若干行纯数字坐标。这种设计在绘图脚本里极方便——脚本只要跳过#开头的行把剩下两列当经纬度喂给绘图命令就完事了。代价是它几乎不携带元信息没有要素 ID、没有字段定义、没有坐标系描述几何类型也只是靠一个标记字符串表示。所以 OGR GMT 驱动的核心工作是给这套极简文本套上一层 OGR 的数据模型外壳。具体做三件事把每个.gmt文件识别成一张表图层把段头里的标记解析成几何类型和包络框把数据行的坐标还原成OGRGeometry。反向则是把OGRFeature拆回文本行。听着简单但真正的复杂度全在边界情况上——空段、混合几何类型、多环面、带 Z 值的点、只有一列的数据行。我遇到那个项目里的文件就是这样大部分是线但有几个文件里混着点段全在一个.gmt里。这种一个文件一种几何类型的约定一旦被打破读取结果就很考验驱动的容错设计。1.2 OGR 视角下的结构一个文件一堆段在 OGR 的模型里一个.gmt文件打开后是一张表。表里每一行就是一个要素。但文件物理上是段组织的一段可能对应一个要素也可能对应一个多部件要素的某个部件。这个映射关系是理解整个驱动最关键的认知点。举个直观的对比Shapefile 里一个.shp是明确的一条记录一个要素记录长度写在文件头里边界清清楚楚。.gmt没有长度前缀也没有索引解析器只能一行一行往下读靠遇到新的#头记录或者遇到独立的分段符来判断上一段结束了。这就是为什么这个驱动内部的读取逻辑是一个典型的流式状态机而不是随机访问——它天然没法随机访问。按常见实践补充一点正因为没有索引GetFeatureCount()这类操作在较老的实现里可能返回-1未知得靠GetNextFeature逐条遍历才能知道总数。写脚本时别假设GetFeatureCount()一定有准数。1.3 能力边界对照表上手前先看这张表比翻文档快能力项支持情况说明读取点支持每行一个点读取线支持一段一条线支持拆环读取面支持依赖闭合环 分段符读取多点/多线/多面支持段头类型标记为 MULTI 系列时图层字段极其有限通常只能承载一个属性字段别指望多列写坐标系不支持读写都不处理 SRS这是硬伤空间索引无属性过滤和空间过滤都是全表扫描创建文件支持-f GMT随机更新不支持要改内容只能整体重写事务不支持无编码纯 ASCII 假定非 ASCII 属性容易出问题把这些当成一份使用前须知能省掉你至少两轮试错。特别是 SRS 那一行我见过太多人往里面塞投影信息写完发现文件里根本没有还以为是工具坏了。2. 格式拆到底头记录、坐标行与分段符我习惯把这种文本格式拆到能手写出一个合法文件的程度再动手写代码。因为一旦你能手写任何读取异常都能用二分法定位到底是文件本身不合法还是驱动理解得不对。2.1 头记录里的 字段逐个说头记录就是一行以#开头的文本后面跟着若干以开头的标记块用空格隔开。这些标记块是格式的全部元信息。常见的几个V格式版本最常见的是VGMT1.0。这一项主要是给读取方一个这是新式 GMT 矢量文件的信号。G几何类型标记取值一般是 OGR 几何类型的名字比如POINT、LINESTRING、POLYGON以及它们对应的MULTI版本。这个字段决定了驱动构造什么样的OGRGeometry。R区域包络格式是xmin/xmax/ymin/ymax。注意顺序是经度最小/经度最大/纬度最小/纬度最大跟 OGR 的Envelope的排列顺序xmin/ymin/xmax/ymax不一致。这个坑我在两个项目里都踩过读起来没报错但算出来的范围整个错位。N属性字段名。驱动通常只维护一个属性字段字段名就写在这里。T属性字段类型比如字符串、整型、浮点。J投影参数形式类似e-71.5/46.5/3。这一项很关键——它看起来像坐标系信息但 OGR 驱动基本不解析它读进来GetSpatialRef()还是空。别指望靠它恢复 SRS。注意不同工具生成的头记录里字段的出现顺序和完整性差别很大。有的只写V和G有的连V都没有。读取端的容错设计是能认的认认不了的忽略缺G时按数据行内容兜底推断。这也是我建议的一个习惯手头拿到一个来源不明的.gmt先head -3看一下头记录长什么样比直接扔给 ogrinfo 更省时间。头记录里少一个G后面所有几何类型的判断都可能跑偏。2.2 坐标行与 分段符数据行就是一行若干列空白分隔的数字。绝大多数情况是两列x、y也可能三列x、y、z。列与列之间用空格或者制表符都行行尾的空白会被忽略。分段符是一个单独的字符起始的行后面可以跟文字说明驱动通常只看第一个字符。它在两种场景下出现第一种是多部件要素。比如一个多面要素外环一段、内环一段中间用隔开。驱动读到就知道上一段几何到此结束下面开始的是同一个多部件要素的下一个部件。第二种是一个文件里多个独立要素共用同一份头记录。有些工具为了省字节只写一次头后面用分隔若干个独立要素。这种情况下驱动的处理就依赖于它把解释成部件分隔还是要素分隔这部分行为在不同版本里不完全一致实测下来建议如果你要生成.gmt给别的系统吃别图省事共用头记录每个要素老老实实写一份完整头。我吃过一次亏。为了压缩文件体积我把 4 万个点全部塞进一个头记录下面用分隔。结果我们自己的 OGR 读出来是对的但客户那边的老脚本读出来只画了第一个点。查了半天是人家的解析器把当成整个数据块结束。这种双方都觉得自己没错的问题最后只能靠统一写法解决。2.3 属性是怎么塞进去的这是这个格式最别扭的部分。文本格式本来就没给属性留位置驱动只能用一种约定的方式承载头记录里用N声明一个字段名、T声明类型数据行的最后一列放属性值。结论很明确一个图层基本只有一个字段可用。如果你把一个带十几个字段的 GeoPackage 转成 GMT最后大概率只剩一个字段其余全丢。这个行为不是 bug是格式本身的容积决定的。实际项目里我的处理方式是这样需要多字段信息时把关键字段拼成一个分隔符连接的字符串塞进那唯一一个字段里回头读的时候再按分隔符拆开。虽然丑但省事且不丢信息。至于中文纯 ASCII 假定是这套格式的底色实测中非 ASCII 字符能不能完整往返取决于文件编码、驱动版本和系统 locale 三者建议直接在源头把中文转成拼音或者 ID别赌。2.4 三份手写样例三份最小的可读样例点、线、面各一份。手敲一遍你对这个格式的理解会比读十页文档扎实。# VGMT1.0 GPOINT R116.0/116.5/39.5/40.0 Nname Tstring 116.10 39.60 A1 116.20 39.70 A2 116.30 39.80 A3三个点每行最后一列是那个唯一属性的值。# VGMT1.0 GLINESTRING R116.0/116.5/39.5/40.0 Nname Tstring 116.10 39.60 116.20 39.70 116.30 39.80 T1注意线的属性写在最后一行行尾不是写在头记录里。这个细节在手工造测试数据时特别容易搞错。# VGMT1.0 GPOLYGON R116.0/116.5/39.5/40.0 Nname Tstring 116.10 39.60 116.30 39.60 116.30 39.80 116.10 39.80 116.10 39.60 P1 116.15 39.65 116.20 39.65 116.20 39.70 116.15 39.70 116.15 39.65带内环的面环之间用隔开。首尾点要闭合否则部分驱动版本会当成未闭合环处理读出来可能变成线。3. 读写实操从 ogrinfo 到 Python命令行是探索阶段最快的工具。我一般先用ogrinfo摸清楚驱动怎么理解这个文件再决定用ogr2ogr还是写脚本。3.1 三行命令摸清一个陌生文件第一步永远是把驱动的能力打出来确认你装的环境里真的有这个驱动ogrinfo --format GMT输出里能看到驱动支持的数据集扩展名、是否支持创建、支持哪些几何类型。如果这条命令没输出说明你的 GDAL 构建里把这一块裁掉了后面的操作都不用试了。第二步只读元信息不碰数据ogrinfo -ro -al -so sample.gmt-so是 summary only此时你会看到图层名、几何类型、要素数可能是-1、字段列表、范围。这一条命令就能验证三件事几何类型对不对、字段有没有丢、包络框合不合理。范围那项尤其好用——如果范围明显偏了一个量级多半是R的排列顺序被误解或者数据里混进了比例尺之类的奇怪数值。第三步抽几条看实际值ogrinfo -ro -al -limit 3 sample.gmt到这里如果结果不对就基本可以断定是文件自身的问题而不是你的代码问题。3.2 ogr2ogr 的双向转换与 -lco转出GMT 转现代格式最省心ogr2ogr -f GPKG out.gpkg sample.gmt -nln track转回现代格式转 GMT要注意两点ogr2ogr -f GMT out.gmt source.gpkg -nln track -select name一是必须显式写-f GMT靠扩展名猜是不可靠的。二是强烈建议用-select只保留一个字段。既然格式只装得下一个字段那就主动选那个最重要的别让驱动随机挑一个——尤其当源表第一个字段是内部 ID 的时候随机挑的结果就是把一堆无意义的数字写进了属性。批量转换可以用 shell 循环for f in input/*.gmt; do base$(basename $f .gmt) ogr2ogr -f GPKG output/${base}.gpkg $f -nln $base done日志留一份很重要因为批量跑完你很难回忆哪个文件当时报了 warning。加-progress能看到进度快速定位卡在哪个文件。提示ogr2ogr转换 GMT 时方向性错误不会报错只会静默生成一个空图层或者属性全空的结果。所以流水线里一定要加一步校验转换后ogrinfo -so检查要素数是否大于零、字段是否非空。3.3 Python 端读写用osgeo.ogr直接操作控制力最强from osgeo import ogr drv ogr.GetDriverByName(GMT) if drv is None: raise RuntimeError(GMT driver not available) ds drv.Open(sample.gmt, 0) # 0 read only lyr ds.GetLayer(0) print(geom:, ogr.GeometryTypeToName(lyr.GetGeomType())) print(fields:, [lyr.GetLayerDefn().GetFieldDefn(i).GetName() for i in range(lyr.GetLayerDefn().GetFieldCount())]) for feat in lyr: g feat.GetGeometryRef() env g.GetEnvelope() # (xmin, xmax, ymin, ymax) print(feat.GetFID(), g.GetGeometryName(), env)GetEnvelope()返回的顺序和R一致都是xmin, xmax, ymin, ymax这点倒是挺贴心但它跟OGRGeometry.GetEnvelope()在别的地方的用法又有差异写代码时最好显式拆包成变量名别靠位置记。写出from osgeo import ogr, osr drv ogr.GetDriverByName(GMT) ds drv.CreateDataSource(out.gmt) lyr ds.CreateLayer(track, geom_typeogr.wkbLineString, options[]) fd ogr.FieldDefn(name, ogr.OFTString) lyr.CreateField(fd) feat ogr.Feature(lyr.GetLayerDefn()) feat.SetField(name, L1) line ogr.Geometry(ogr.wkbLineString) line.AddPoint_2D(116.10, 39.60) line.AddPoint_2D(116.20, 39.70) feat.SetGeometry(line) lyr.CreateFeature(feat) feat None ds None # 必须显式释放否则缓冲没刷盘最后那两行 None是老生常谈但真的会坑人。GDAL 的 Python 绑定靠引用计数触发 flush脚本跑到一半崩溃文件就是半个。我见过太多写出来的文件只有第一条要素的案例追根溯源都是没释放数据源对象。3.4 批量脚本与目录级处理需要处理的文件一多最麻烦的其实不是转换本身而是哪些文件读失败、失败在哪里。我的做法是把读取包成函数只返回结构化结果把异常都吃掉转成状态def probe(path): from osgeo import ogr drv ogr.GetDriverByName(GMT) ds drv.Open(str(path), 0) if ds is None: return {file: path.name, ok: False, reason: open_failed} lyr ds.GetLayer(0) n lyr.GetFeatureCount() if n 0: n sum(1 for _ in lyr) lyr.ResetReading() return {file: path.name, ok: n 0, reason: if n 0 else empty_layer, count: n, geom: ogr.GeometryTypeToName(lyr.GetGeomType())}GetFeatureCount()返回负数时用遍历兜底这一段很关键不然你会把计数未知误判成是负数所以有问题。较新的 GDAL 版本里把一个目录路径传给驱动有时能展开成多图层每个.gmt一个但这一行为随版本变化我不敢把它写进生产脚本。稳妥做法还是自己遍历目录、逐文件打开。4. 源码实现从注册到游标前面说了这个驱动本质上是文本流的 OGR 适配层。看懂它的实现你能省掉大量试错尤其是那些看着没毛病但就是读不出来的问题。4.1 驱动注册与 Open 的分流OGR 驱动的入口是注册函数注册时把元数据和回调函数指针挂上去。简化后的骨架大致是这样void RegisterOGRGMT() { if (GDALGetDriverByName(GMT) ! nullptr) return; GDALDriver *poDriver new OGRGMTDriver(); poDriver-SetDescription(GMT); poDriver-SetMetadataItem(GDAL_DCAP_VECTOR, YES); poDriver-SetMetadataItem(GDAL_DCAP_CREATE, YES); poDriver-SetMetadataItem(GDAL_DCAP_CREATECOPY, YES); poDriver-SetMetadataItem(GDAL_DMD_EXTENSIONS, gmt); poDriver-pfnOpen OGRGMTDriverOpen; poDriver-pfnCreate OGRGMTDriverCreate; poDriver-pfnDelete OGRGMTDriverDelete; GetGDALDriverManager()-RegisterDriver(poDriver); }注意GDAL_DMD_EXTENSIONS只登记了gmt。这意味着靠扩展名自动识别是可行的但如果你手上的文件后缀是.txt或者别的自动识别就会失败Open会返回空。这类打开失败的问题八成不是文件坏了而是扩展名对不上——解决办法是强制指定驱动而不是加后缀。在 Python 里就是先GetDriverByName(GMT)再调Open绕开自动识别。OGRGMTDriverOpen里做的事情很少先按扩展名和文件头做一次快速判断然后构造OGRGMTDataSource让它去真正打开。4.2 数据源与图层的构建数据源这一层主要负责一个文件 → 一张表的映射。它的Open里通常做这几件事检查路径存在、判断是普通文件还是目录、如果是目录则扫描其中的.gmt并逐个子图层打开。图层对象建立时会先做一次探测性读取打开文件流读到第一行#头记录解析出几何类型、字段名、字段类型把OGRFeatureDefn建好。这一步决定了后面GetLayerDefn()返回什么。这里有个很实际的现象如果文件头记录里没有G几何类型就只能等读到第一条数据才能确定。这时候GetLayerDefn()在被调用时可能返回wkbUnknown。我在写通用转换工具时吃过这个亏——先读GetGeomType()再决定处理逻辑结果拿到wkbUnknown直接走了异常分支但文件其实是好的。稳妥的做法是先调一次GetNextFeature()再ResetReading()然后读几何类型。用一条记录换一个确定的类型这笔买卖很划算。4.3 读路径的状态机这是整个驱动最值得看的地方。GetNextFeature()本质上是个循环推进的状态机逻辑简化下来是这样OGRFeature *OGRGMTLayer::GetNextFeature() { while (true) { const char *pszLine ReadLine(); if (pszLine nullptr) { // EOF把累积中的几何收尾吐出去 return EmitPendingFeature(); } if (pszLine[0] #) { ParseHeader(pszLine); // 更新类型、字段、范围 continue; } if (pszLine[0] ) { // 段结束结束当前环/当前部件 CloseCurrentRingOrPart(); continue; } if (IsBlank(pszLine)) continue; AppendVertex(pszLine); // 追加一个坐标点 } }真实实现当然更啰嗦但结构就是这样。看懂这段很多现象都能自己解释为什么只读到第一条EOF 分支里EmitPendingFeature之后没有重置状态或者上层没再次调用。为什么面读成了线分段符没被正确处理闭环逻辑没触发。为什么计数是 -1整个流程是纯流式的不预先扫描文件所以数量只能边读边数。还有空间过滤和属性过滤。标准的 OGR 驱动在GetNextFeature里会应用m_poFilterGeom和m_poAttrQuery。但对这个驱动大概率是读完再过滤因为文件里没有索引可用。这意味着对一个 50 万点的文件做一次范围查询耗时和全表扫描一样。这个认知很重要能帮你避免写出 O(n²) 的批处理脚本。4.4 写路径与头记录生成写入的关键在于头记录只写一次。驱动内部会维护一个m_bHeaderWritten之类的标志OGRErr OGRGMTLayer::ICreateFeature(OGRFeature *poFeature) { if (!m_bHeaderWritten) { CPLString osHeader # VGMT1.0 G; osHeader OGRGeometryTypeToName(GetLayerDefn()-GetGeomType()); // R 由几何包络填入顺序固定 xmin/xmax/ymin/ymax // N/T 由第一个字段的定义填入 WriteLine(osHeader); m_bHeaderWritten true; } WriteGeometryAndAttributes(poFeature); return OGRERR_NONE; }这里有个隐性的坑R是在写第一条要素时用那条要素的包络填的而不是整个图层的包络。也就是说后写入的要素如果超出了第一条的范围头记录里的R就是错的。有些下游工具会拿R做初始视窗设置结果图画出来只显示了一小部分。我在项目里的处理是生成.gmt时先自己算一遍整体包络一条条写完之后再回头把第一行重写掉。文件不大时直接内存里拼好一次性写最干净。4.5 编译与断点调试需要改驱动行为时才走到这一步。常规做法是构建 GDAL 时打开调试符号然后用--debug on看驱动层面的日志ogrinfo --debug on -al sample.gmt 21 | head -50日志里会打出驱动被尝试加载、打开、失败的顺序。如果 GMT 驱动根本没出现在尝试列表里那说明是加载阶段的问题跟你文件内容无关。想直接断点可以在GetNextFeature的 EOF 分支和分支各下一个断点跑一个三要素的小文件单步走一遍。走完之后你会对什么时候吐要素有完全不一样的理解比读代码快得多。我在排查一个多面只读出第一个环的问题时就是这么干的最后发现是处理完之后没把当前环追加进多面容器。5. 常见问题与排查实录这一节全部来自真实排查记录按出现频率从高到低排。5.1 打开成功但要素为零最常见的场景路径没错、文件不空、ogrinfo也不报错就是 0 条要素。三个可能。一是头记录之后的东西全被当成注释。有些工具生成的头记录会连续写好几行#开头的说明文字如果驱动把第一个#之后的#行当成新的段头并重置状态前面累积的坐标就没了。二是数据行前面有前导空格被当成空行跳过了。三是字段分隔符不是空白而是逗号。排查顺序建议固定成这样先head -5看前五行再grep -c ^#数头记录行数最后awk {print NF} | sort -u看每行的列数分布。列数出现预料之外的取值比如大部分是 2但有几行是 5基本就能锁定问题。5.2 面被读成线 / 环被连错面读成线几乎只有一个原因环没闭合或者的位置不对。这个格式没有这个环是外环还是内环的显式标记全靠顺序和闭合性推断。我遇到过一个更隐蔽的情况面文件里最后一个点跟第一个点数值上相同但一个是116.10一个是116.100。字符串比较不相等浮点比较相等不同版本的闭合判断用不同的比较方式结果就不一致。解决办法是在生成端统一格式化用固定精度输出。5.3 属性丢字段、中文乱码字段丢失是格式容量决定的不是 bug。源数据有 12 个字段写出后只剩 1 个正确行为。中文乱码则要看两边。如果文件里是 UTF-8 而读取端按 latin-1 解就会变成一堆问号或者乱码方块。这类问题不要试图在 OGR 层面修源头转成 ASCII 更省心。我现在的标准做法是属性值只放编号P001、T017这种编号到名称的映射单独维护一张表。5.4 大文件与内存.gmt没有索引所有操作都是全表扫描。10 万行以内的文件随便折腾上到百万级就要注意了。几个实测有效的做法读取时用流式遍历for feat in lyr不要先GetFeatureCount()再切片过滤条件尽量在读取之后自己筛别指望驱动帮你优化写大文件时按块提交别在内存里攒几万个OGRFeature对象那个内存占用比你想象的高得多。5.5 问题速查表现象最可能的原因处理办法打开返回空扩展名不是.gmt显式GetDriverByName(GMT)后 Open要素数为 0头记录之后全被当注释检查是否连续多行#只读到第一条数据源未释放 / 未 ResetReading显式ds None面读成线环未闭合或位置错误校验首尾点严格相等范围明显错位R顺序是 xmin/xmax/ymin/ymax手工核对头记录坐标系为空格式本身不承载 SRS转换后单独补 SRS字段只剩一个格式容量限制用-select主动选中文变乱码编码不匹配源头转 ASCII 或编号写入后文件不完整未 flush显式释放数据集对象大批量转换很慢无索引全表扫描分片处理避免重复打开6. 什么时候别用它边界与取舍写到这儿得说点反向的话——这个驱动不值得被当成主力格式用。它的价值在桥不在仓。6.1 与主流矢量格式的取舍如果链路两头都是现代工具那就别引入.gmt。GeoPackage 有索引、有事务、有完整字段、有 SRS任何一维度都碾压。只有在一种情况下.gmt是正确答案下游有现成的脚本或工具只认这个格式且改动成本高于适配成本。我做过一次评估把这个格式和几条常见路径摆在一起比过维度GMT ASCII VectorsGeoPackageGeoJSON字段容量1 个无限制无限制坐标系不承载完整可选可读性人眼可读二进制人眼可读体积小中大随机访问不支持支持不支持老脚本兼容极好差一般结论很清楚它的唯一优势是老工具能直接吃和人眼能看能 diff。所以我的用法固定为——.gmt只出现在系统边界进入内部立刻转成 GeoPackage出去时再从 GeoPackage 导出。中间层永远不用它。6.2 版本兼容的坑同一份.gmt不同 GDAL 版本读出来的结果可能不一样。我实测过的主要差异点有两个字段名从N解析时的边界处理以及被当作部件分隔还是要素分隔。应对办法只有一个在 CI 里放一份固定的小样例每次升级 GDAL 版本都跑一遍回归比对要素数、几何类型、包络框、属性值四项。这个成本极低但能挡住绝大多数静默错误。样例文件不需要大三个点、一条线、一个带洞的面就够了。6.3 回归测试怎么写我的写法是用ogrinfo -so的输出做快照比对简单粗暴但有效ogrinfo -ro -al -so fixtures/sample.gmt actual.txt diff -u fixtures/expected.txt actual.txtexpected.txt里把要素数、几何类型、范围、字段列表都记下来。版本升级导致输出变化时diff 会直接告诉你哪一项变了比人肉检查快十倍。如果不想依赖命令行用 Python 写断言也可以def test_gmt_roundtrip(tmp_path): from osgeo import ogr src fixtures/sample.gmt drv ogr.GetDriverByName(GMT) ds drv.Open(src, 0) lyr ds.GetLayer(0) assert ogr.GeometryTypeToName(lyr.GetGeomType()) Line String n sum(1 for _ in lyr) assert n 1一次真实的数据丢失事故让我记住了这个格式一套出图脚本的上游数据换了来源新数据的包络顺序不符合R的约定生成的图整片偏移。排查花了整整两天最后发现是三个字符的顺序问题。从那以后我在所有涉及这个格式的转换节点上都加了范围校验——转出前后各算一次包络差值超过阈值就直接失败不让错误数据流到下游。这种笨办法其实最划算它把一次两天的排查变成了一次两秒的失败。另外补一个小技巧手工造测试数据时别用真实业务数据裁剪直接手写一个最小样例。业务数据里总有些边界值会干扰判断最小样例能让每次失败的原因都指向唯一。我现在维护的那份 fixture 只有 12 行涵盖点、线、带洞面、多部件和空段五种情况两年来抓出过三次驱动行为变化带来的回归。这个投入产出比在任何项目里都算高的。
