1.2 MapGIS产品体系与加工链全景

1.2 MapGIS 产品体系与加工链全景

本节摘要：MapGIS 是一个覆盖"数据管理、桌面制图、服务发布、二次开发"全链条的国产 GIS 平台家族，本节按加工链工位把产品线摆开，并交代 6.7 经典版到 10 系列的演进关系。读完你能为任意一项任务迅速指到对应产品，也能读懂存量项目里那些旧文件后缀的来历。

从一个选型电话说起

朋友的测绘公司接了个活：给一个开发区做地下管网普查建库，要求交付数据入库、桌面查询工具，再挂一个网页端给管委会看图。他打电话问我买哪款软件。我的回答是先别看软件，先把任务拆到加工链工位上——采集校核、建库管理、分析制图、服务发布、轻量定制，五个工位五种能力。拆完再看 MapGIS 的产品货架，选型就从"听销售介绍"变成了"按单取货"。

这张货架的大致格局如下（以 MapGIS 10 系列为主线）：

# MapGIS 产品货架按加工链工位对照（简化版，具体版本以官方发布为准）
工位            承担产品                     关键能力
数据管理        地理数据库（本地HDB/挂接主流库）  要素类、栅格数据集、 版式与权限
桌面加工        MapGIS Desktop（标准/专业等档位） 编辑、拓扑、分析、制图、整饰
服务出厂        MapGIS IGServer                地图/要素/瓦片服务， REST接口
多端消费        客户端开发包（JavaScript等）     浏览器、大屏、移动端集成
产线定制        二次开发包（C++/C#/Java等组件）  组件式、插件式、服务端开发
辅助工具        工具箱与脚本环境               批量转换、自动化处理
# 注：同一工位常有多个档位版本，档位差异主要体现在授权的功能模块上
​

理解这个货架的关键不是背产品名，而是记住一个事实：一条完整的加工链可以全部用同一家平台的产品串起来。数据从桌面端加工后直接入库，IGServer 读同一个库发布服务，开发包调同一套接口——数据不落地转换，就不产生精度与编码损耗。这是选型时最容易忽略的隐性收益。

图：MapGIS 产品与加工链工位对应

回到朋友的选型单

现在可以回答开头那通电话了。管网普查建库项目拆解后：外业采集校核用移动端，内业建库用桌面端加地理数据库，管委会看图用 IGServer 加一个轻量网页——轻量到甚至不需要完整二开，用客户端开发包写几十行代码就够。他最初想买的"一款软件"，实际是一组工位组合。

把这次选型整理成一张可复用的决策清单：

# 任务到产品的映射清单（拿到新项目先填这张表）
任务要素            问题                          落点
数据存哪里          单机还是多人并发编辑           本地HDB 或 挂接企业级数据库
谁来加工            内业人员数量与技能             桌面端档位与授权数量
给谁看              内部局域网还是互联网           IGServer 部署模式与端口策略
要不要定制          现有功能能否覆盖业务流         组件式 / 插件式 / 仅脚本
存量数据是什么      文件型还是库型，哪个版本       数据迁移与升级工作量估算
# 经验：第三行和第五行最容易被低估，返工成本也最高
​

这张表在后续第 6 章选型决策树里会升级成完整版。这里先埋一个钩子：选型时评估的不是软件强弱，而是数据流向的顺畅程度。数据每多一次手工转换，就多一次出错机会。

读懂存量项目：6.7 到 10 的演进

实际工作中你会不断撞见历史包袱。某县局的档案室里，2005 年的地质图还是 6.7 的点线面文件，2015 年的土地利用库已经进了 10 的地理数据库，两个项目要拼在一起做分析。这时需要理解两代体系的本质差异：6.7 以文件为组织核心，点、线、面分文件存放，属性与图形伴生；10 系列以数据库为组织核心，所有数据类型统一收纳进库，靠目录与权限管理。

差异带来的实际影响：

# 两代体系关键差异对照
维度          MapGIS 6.7 经典版              MapGIS 10 系列
组织核心      文件（wt wl wp mpj）           地理数据库（本地HDB或挂接主流库）
并发能力      单机为主，共享靠网络盘          多用户并发编辑，带版本与权限
服务能力      依赖独立服务器软件              IGServer 直接读库发布
升级动作      无需升级，直接使用              数据迁移入库，重设空间参照
典型场景      存量资料查阅、老项目维护        新建项目、服务化、二次开发
# 提示：老文件参与新项目前，先做第2.2节的坐标核对，再决定是否迁移入库
​

⚠️ 常见坑：把 6.7 的文件直接复制进 10 的库目录下就以为完成了迁移。正确做法是用数据迁移工具转换，转换过程中几何与属性各有一次校验机会，跳过校验等于把旧伤带进新库。

💡 关键直觉：平台演进的主线是"数据从文件走向数据库、从单机走向服务"。看懂这条主线，任何 GIS 平台的新版本发布你都能猜到它在补哪块短板。

版本与授权：采购前必问的五件事

选型清单填完，进入采购谈判前还有五件事必须问清，它们决定项目后三年的舒适度。一问授权方式：加密狗、浮动许可还是云端授权，浮动许可适合多人轮流使用的科室，加密狗适合固定工位。二问档位边界：桌面端的标准版与专业版差在哪些模块，拿着清单对需求，别为用不到的模块付钱。三问升级政策：大版本升级是否另行计费，锁版本的项目三年后会发现新数据格式读不了。四问开发包分发：二开成果分发给用户时，运行时组件的授权怎么算——这直接影响交付成本。五问服务响应：就近有没有服务网点，紧急故障的响应时效写进合同的哪一条。

# 采购谈判检查单（五问五记）
问授权方式    记入：工位数 并发数 授权载体
问档位边界    记入：需求模块与档位功能对照表
问升级政策    记入：大版本升级费用与周期条款
问运行时分发  记入：二开成果交付时的授权成本
问服务响应    记入：响应时效与就近网点
# 提醒：五问的答案都要求写进合同附件 口头承诺在验收纠纷时一文不值
​

顺带回答一个衍生疑问：开源 GIS 能不能替代商业平台？ 能力层面大量场景可以，但两个差距要掂量——行业合规链路（国土报批的数据格式与服务规范）商业平台开箱即用，开源要自己拼装验证；出了事故的责任归属，商业平台有厂商兜底条款，开源只有社区。技术团队强、合规要求低的项目，开源值得认真评估；反之，把不确定性买走，正是商业授权费的一半含义。

本节要点回顾

• 货架思维：按仓储、加工、出厂、分销、改造五个工位理解产品线，选型变成按单取货
• 隐性收益：同一家平台串起全链，数据免于反复转换，精度与编码损耗最小
• 选型本质：评估数据流向的顺畅程度，而不是软件功能列表的长短
• 两代体系：6.7 文件型与 10 库型并存于现实项目，迁移必须走工具不能靠复制
• 决策清单：存储、加工、分发、定制、存量五问，拿到项目先填表再谈软件

下一节钻进原料本身：矢量与栅格两种数据形态的成本、精度与适用边界。