GDAL MiraMonVector 驱动：读写 MiraMon 结构化矢量图层（.pnt / .arc / .pol）的完整指南

• GIS
• 遥感
• 数据工程

本文基于 GDAL 仓库官方驱动文档doc/source/drivers/vector/miramon.rst，完整讲解 MiraMonVector 向量驱动的能力边界、MiraMon 多文件（sidecar）文件集结构、编码规则、打开选项与创建选项，并结合ogr/ogrsf_frmts/miramon/下的 C/C++ 源码与autotest/ogr/ogr_miramon_vector.py测试用例，说明各选项的底层实现与验证方式。读完本文，你可以直接使用ogr2ogr在 MiraMon 矢量格式与 GML、DXF 等常见格式之间可靠地做双向转换，并按需控制版本、编码与高度选取策略。

驱动概述与能力边界

MiraMonVector 驱动（短名称MiraMonVector，默认随 GDAL 构建）自 GDAL 3.9 引入，具备读取与写入 MiraMon 结构化矢量格式的能力，支持点（point）、弧（arc，即 linestring）与多边形（polygon）三类要素。

驱动在注册时声明的关键元数据见 ogrmiramondriver.cpp：

• GDAL_DCAP_VECTOR/GDAL_DCAP_CREATE/GDAL_DCAP_CREATE_LAYER/GDAL_DCAP_CREATE_FIELD：支持创建数据集、图层与字段；
• GDAL_DMD_EXTENSIONS为pol arc pnt，即驱动的合法入口扩展名；
• GDAL_DCAP_VIRTUALIO：支持 VSI 虚拟文件系统（测试中即通过/vsimem验证）；
• GDAL_DCAP_Z_GEOMETRIES：支持三维（Z）几何；
• GDAL_DCAP_MULTIPLE_VECTOR_LAYERS_IN_DIRECTORY：一个目录可作为包含多个矢量图层的数据集打开——这正是"输出到文件夹"模式的基础。

对应文档中的三项声明能力：supports_create、supports_georeferencing（从.rel文件读取空间参考系统）、supports_virtualio。

几何类型的映射规则

MiraMon 格式本身不支持 OGR 的复合几何语义，驱动按如下规则转换：

• MiraMon 没有OGRMultiPoints与OGRMultiLineStrings概念：一个 multipoint 会被拆成 N 个 point，一个 multilinestring 会被拆成 N 个 arc（对应源码中的 "Converting multilines and multi points to simple ones"，见 ogrmiramonlayer.cpp）；
• 打开一个*.pol文件时，图层报告的几何类型是wkbPolygon，但具体每个要素的实际类型可能是OGRPolygon或OGRMultiPolygon，取决于该要素的部件（ring）数量；
• 环向自动校正：读入多部件多边形时，驱动会检查其是否符合规范——外环顶点在 X/Y 平面上应为顺时针、内环（孔）应为逆时针；不符合时驱动会自动修正方向。原因在文档中解释得很清楚：原始 MiraMon 多边形文件基于拓扑弧文件（arc-based topology），顶点顺序与规范方向并不总是一致。

另外两个重要的能力限制：

• M 坐标（measures）不受支持；
• 符号化（symbolization）既不读取也不生成——.rel文件中虽含默认符号化描述，但 GDAL 环境只利用其中空间参考系统、元数据语言、扩展名与字段描述等少数方面。

空间参考系统与旧版 .rel 文件的处理

MiraMon 拥有自己的空间参考系统标识符体系，通过 MiraMon 与 EPSG 之间的查找表（look-up-table）匹配两边标识符。驱动数据目录中的 MM_m_idofic.csv 即随驱动分发的 MiraMon/EPSG 标识符对照数据（从源码结构看，打开.rel时用于将 MiraMon SRS 代码换算为 EPSG 代码）。

若图层附带的是几十年前使用的旧版*.rel格式文件，打开时会出现一条警告消息，说明如何将其转换为现代的rel 4文件。

MiraMon 文件集结构：一个图层由多个文件组成

理解该驱动的第一关键是：MiraMon 矢量图层不是一个文件，而是一组同名前缀的文件（前缀在文档中记作FileName，即图层主文件名的第一部分）。它本质上是"二进制矢量几何文件 + dBASE 属性表 + 关系/元数据文件"的组合，可带或不带拓扑，并附丰富的元数据。官方结构化格式规范 PDF 在原始文档 "See Also" 一节中有外链（本文按规范不输出外部链接）。

各类型图层所需的文件集如下：

注意T/A/N/P这类字母是直接拼在扩展名点号之前的（如FileNameT.dbf），这是 MiraMon 命名约定中最容易踩坑的地方。

各文件的职责

• FileName.pnt/FileName.arc/FileName.pol：地理数据库，存放定义要素的坐标。点要素由单个 (x,y) 或 (x,y,z) 坐标描述；线要素由一串坐标段描述，每条线的两端点称为节点（node）；多边形则由一个或多个 arc 围成、可含孔，多个多边形可链接为一组（group，即 multipolygon），FileName.pol中的多边形通过索引引用FileName.arc中的弧。
• FileNameT.dbf/FileNameA.dbf/FileNameP.dbf：主属性表，标准 dBASE (DBF) 格式；若字段过多、记录过大或含长文本，则采用 MiraMon 的 extended DBF（对 dBASE IV 的改进版，规范 PDF 见原始文档 "See Also"）。表内含一个名为ID_GRAFIC的字段，它充当 Feature Identifier (FID)，把每个地理要素关联到一条或多条属性记录。写入实现中ID_GRAFIC作为必建内部字段处理，见 mm_wrlayr.c 等处的建表逻辑。
• FileNameT.rel/FileNameA.rel/FileNameP.rel：图层元数据文件，包含数据库关系结构（主表与其他表如术语表之间的链接及基数）与默认符号化描述。GDAL 环境只使用其中：空间参考系统、元数据语言、扩展名和字段描述。
• FileName.nod/FileNameN.dbf/FileNameN.rel：节点（node）的地理与属性信息，是 MiraMon 拓扑所必需的文件，但GDAL 驱动并不读取它们，因为节点承载的拓扑信息不会转移到其他格式——不过打开时这些文件必须存在。
• 在多边形图层中，FileNameA.dbf/FileNameA.rel描述弧与多边形的关系，与线部分信息冗余，因此同样不被 GDAL 直接读取。

侧车文件名的拼接逻辑可在 ogrmiramonlayer.cpp 中看到，例如FILE_NAME_WITHOUT_EXTENSION.pnt→FILE_NAME_WITHOUT_EXTENSION + T.rel的推导规则。

提供主文件名即可，驱动会自动定位其余 sidecar 文件；创建图层时只需提供主文件名（带或不带扩展名），驱动会创建全部配套文件。读写坐标与 DBF 的核心 C 实现位于 mm_rdlayr.c（读）与 mm_wrlayr.c（写）。

连接字符串（打开方式）

翻译（读写）MiraMon 矢量数据时，输入必须是带有以下扩展名之一的文件：

• *.pnt：点；
• *.arc：线（linestring）；
• *.pol：多边形（或 multipolygon）。

*.nod扩展名不是合法的打开入口，且务必保证上文列出的全部辅助文件齐备。

驱动层的识别（identify）逻辑非常直接：读文件头前 3 个字节必须是PNT、ARC或POL之一，随后 6 个字节是1.1或2.0版本标识，二者同时满足才判定为 MiraMon 矢量文件，见 ogrmiramondriver.cpp。这也解释了后文"尺寸问题"一节中版本选择的重要性——文件头即决定了 32 位还是 64 位偏移布局。

编码（Encoding）

• 读取时：驱动读取.dbf文件头中的代码页设置，并据此把字符串字段统一翻译为 UTF-8——无论原始内容是 ANSI、OEM 还是 UTF-8 编码；
• 写入时：.dbf文件的编码由创建选项DBFEncoding控制，可选ANSI或UTF8。写 REL 4 元数据文件时存在 UTF-8 → ANSI 的字符转换路径（见 mm_wrlayr.c）。

打开选项（Open options，-oo）

以下打开选项在 ogrmiramondriver.cpp 的GDAL_DMD_OPENOPTIONLIST中注册，解析与生效位置在 ogrmiramonlayer.cpp。

Height选项的读取实现位于 mm_rdlayr.c 的MM_AdoptHeight/MM_GetArcHeights，即逐顶点按 First/Lowest/Highest 策略归约 Z 值。

自动化测试对该行为做了参数化验证：对同一Some3dPoints.pnt多高度点图层分别以Height=First、Height=Lowest、Height=Highest打开，断言第 31 号要素的 Z 值分别为 250.0、250.0、277.0（见 ogr_miramon_vector.py）；OpenLanguage与MultiRecordIndex同样有对应断言用例（同文件）。

数据集与图层创建选项（Creation options）

数据集创建选项：无（文档明确 "None"）。

图层创建选项在 ogrmiramondriver.cpp 的GDAL_DS_LAYER_CREATIONOPTIONLIST中注册：

版本选择在写入实现中对应 mm_wrlayr.c 处对"最终版本是 1.1 还是 2.0"的判断；当数据超出 1.1 容量限制时，驱动会给出类似MiraMon format limitations. Try V2.0 option (-lco Version=V2.0)的提示（见 ogrmiramonlayer.cpp）。

创建问题：输出是文件夹还是文件

MiraMon 一个图层只能存一种几何类型（点、线或多边形三选一）；混合不同类型的图层（包括 WMS/WMTS 等栅格与地理服务）只能通过 MiraMon map 文件（*.mmm）实现。因此创建时的行为分两种：

• 输出是文件夹：翻译后包含源数据集中所有图层，保留原始图层名。驱动还会创建一个*.mmm文件引用源数据集的全部图层，以便在 MiraMon 软件中一键打开；此时必须用-f指定格式名：-f MiraMonVector。.mmm的生成代码见 ogrmiramondatasource.cpp（当输出根名不是 pol/arc/pnt 扩展时创建/复用.mmm并写入[VERSIO]、[DOCUMENT]段）。
• 输出是带扩展名的文件（如*.pol）：源数据集中所有翻译后的图层都写入该指定名，仅当源数据集只有一个图层且只有一种要素类型时才应使用此方式。

属性方面：要素属性存入配套的*.dbf。若经典 DBF IV 表不适用（字段或记录过多、长文本字段等），则改用 extended DBF——这是 dBASE IV 的改进格式，规范 PDF 见原始文档 "See Also"。注意：extended.dbf无法用 Excel 等常规程序打开；若本机没有完整的 MiraMon Professional，可下载免费独立的 MiraD 应用打开（下载页面在原始文档 "See Also" 中，本文不重复外链）。

字段宽度方面：驱动会自动扩展字符串与整数字段，动态容纳待插入数据的长度，创建时通常无需手动指定字段尺寸。

尺寸问题（Size Issues）

• 几何：MiraMon 矢量格式 1.1 版显式使用 32 位偏移，2.0 版使用 64 位偏移。若 2.0 并非确有必要，建议生成 1.1 版本文件——1.x 文件更小；
• 属性：DBF 内部没有偏移量结构，因此属性表可以任意大。

实战命令示例

以下示例完整继承自官方文档，并做了必要的规范化（命令块外的补充说明原文档内嵌在代码中，此处移回正文）。

示例 1：DXF（单图层、多种几何类型）→ MiraMon 文件夹

Example_1.dxf只有一个图层，但图层内混有多种几何类型，翻译到output_folder后，将按几何类型生成 MiraMon 图层文件组（点一组、线一组……）：

ogr2ogr output_folder Example_1.dxf -f MiraMonVector -lco Version=V1.1

输出为文件夹，故必须显式指定-f MiraMonVector。

示例 2：DXF（单一多边形图层）→ 单个 MiraMon 图层

将Example_2.dxf中唯一的多边形图层翻译为territories.pol，并让.dbf使用 UTF-8 编码：

ogr2ogr territories.pol Example_2.dxf -lco DBFEncoding=UTF8

输出是带扩展名的文件而非目录，因此无需-f MiraMonVector（由扩展名.pol即可确定格式）。此方式的前提是你确认源数据集只有一个图层、一种要素类型。

示例 3：MiraMon 线图层 → GML（多值字段只取第一个）

从弧图层rivers.arc翻译为rivers.gml，仅保留属性表多记录（List 字段）的第一个元素：

ogr2ogr rivers.gml rivers.arc -oo MultiRecordIndex=1

示例 4：多高度图层 → GML（取每个点的首个高度）

ogr2ogr tracks.gml tracks.arc -oo Height=First

示例 5：多高度图层 → GML（Catalan 元数据语言）

文档原文示例写作-oo Height=First -oo Language=CAT（并说明"取每个点最后一个高度"，即与参数值First不一致）。对照驱动注册的打开选项，正确名称应为OpenLanguage（且若确要取最后一个高度应为Height=Last之类的取值），规范化后的命令为：

ogr2ogr tracks.gml tracks.arc -oo Height=Last -oo OpenLanguage=CAT

源码与测试佐证

围绕本驱动的核心证据路径，便于进一步深入：

测试用例的覆盖面印证了本文描述的各能力：简单点/线读写及 WKT 逐坐标断言、Version取V1.1/V2.0/last_version甚至非法值的参数化写后回读（round-trip）验证、3D 点/线/面（如linies_3d_WGS84.arc、tin_3d多边形组）的高度断言、以及Height/OpenLanguage/MultiRecordIndex的打开选项断言。写入验证统一采用"VectorTranslate 输出到/vsimem→ 重新打开 → 与源数据逐字段比对"的模式，证明读/写路径对坐标、ID_GRAFIC、布尔字段子类型（OFSTBoolean）乃至长度字段（N_VERTEXS、LONG_ARC、NODE_INI/NODE_FI）都能保真。

小结与适用前提

• 打开输入只能是*.pnt/*.arc/*.pol且侧车文件齐全；.nod不是合法入口，节点表文件存在但不被读取；
• 一个图层一种几何类型；混合输出走"文件夹 +.mmm"模式并显式-f MiraMonVector；
• 数据规模受版本影响：默认Version=V1.1（32 位，文件小），超出 FID/偏移/实体数上限时改用-lco Version=V2.0；
• 编码默认DBFEncoding=ANSI，追求跨软件可编辑性时保持 ANSI，需要 Unicode 属性时再切换UTF8（extended DBF 无法用 Excel 打开）；
• 复合几何会被拆散、环向被自动校正、M 坐标与符号化不在转换范围内——这些是该驱动与通用 OGR 语义之间的固定边界，做数据迁移规划时应提前考虑。

• GIS
• 遥感
• 数据工程