GIS融合之路（一）技术选型CesiumJS/loaders.gl/iTowns

大家好，我是山海鲸的技术负责人。今天来和大家分享一下山海鲸可视化在数字孪生系统当中对GIS系统的整合之路，大家可以移步视频教程中看一下目前的整合效果。

熟悉山海鲸的朋友应该知道，山海鲸可视化在3.0之后，在软件内部整合了一个3D场景编辑组件-城市大师。城市大师当中不仅实现了体积云天空，Lensflare，雨雪天气，高度指数雾等等特效，也整合了模型库，PBR材质编辑，植被笔刷，标记点，热力图等等非常好用的3D编辑功能（有兴趣的朋友可以下载试一试: 山海鲸可视化-一站式数字孪生开发平台-海量数据可视化大屏模板）。经过了一年时间的加班打磨，作为技术负责人的我终于觉得可以躺下来好好喝杯咖啡了。然而，天不遂人愿。咱们做TOB的人有一个永远的诅咒，那就是软件的开发永远跟不上客户的需求变动的速度。在接触大客户的过程中，GIS系统不断被提及。特别是大部分智慧城市项目，几乎都有自己的测绘数据，DEM，DOM，倾斜摄影等数据，都需要接入到山海鲸的可视化系统当中。问题来了，到底怎么才能把这些GIS数据接入到山海鲸当中，还能共享城市大师中所有的功能呢？

如果是一家没有技术追求的公司，那肯定是CesiumJS拿来用。但是我们不一样啊，作为一个有理想的技术负责人，渲染都不愿意用成熟游戏引擎，要自己来实现。更何况GIS这种纯粹功能的东西，必须要自己写啊。想到这，当然是说干就干：先搞清楚这些GIS名词是啥。

经过一番仔细研究和认真研判（对，就是搜索了几个关键词），最终发现自己还是太年轻。GIS行业的人都不上网的吗？咋没有一个大神出来写一篇GIS从入门到精通呢？这些词这么多，咋解释的文章这么少，还全是抄来抄去的。

要不先看看CesiumJS代码吧，再次经过一番仔细研究和认真研判，发现自研道路道阻且长，作为一个有理智的技术负责人，此时应为整个团队着想，果断放弃自研道路。

目前根据搜索到的信息，有三条路可以走（由于我们采用的Webgl引擎相对小众且做了大量修改，所以搜索时基本都只能搜索ThreeJS的相关内容，因此下面我用CesiumJS和ThreeJS的整合方式来代表和我们的引擎的整合方式）：

1.整合CesiumJS到系统中

优势：CesiumJS的非常成熟，几乎支持了大部分常用的GIS协议，且性能优化较好

劣势：CesiumJS自己实现了底层的渲染功能，无法直接嫁接到我们的渲染引擎当中。

2.给iTown写一个中间件

优势：iTown底层是基于Threejs的，起码能看懂，好嫁接

劣势：iTown本身不成熟，即使整合成功可能会面临额外工作

3.使用loaders.gl加载成功后，直接写入渲染引擎

优势：开发起来自由灵活，类似自研

劣势：对tiles的加载几乎需要自己实现。

最终，考虑到最终客户对于稳定性的需求，以及研发时间的限制，决定选择CesiumJS整合这条路径。然后经过一番深入的研究发现这条路实际也是道阻且长，网上仅搜索到了几篇文章谈到了ThreeJS和CesiumJS的整合方式。

(1) 直接将两个Canvas叠加到一起，并同步相机实现。这种实现方式远不能满足我们深度整合的需求。

(2) 采用CesiumJS的DrawCommand来实现ThreeJS的渲染底层，这种方式整合程度更深，但我们本身已经在自己的渲染引擎中做了太多的定制，几乎不可能在这个时候迁移到CesiumJS的DrawCommand当中去。

那么有没有既不需要动目前的渲染引擎底层，又不至于像是两个Canvas这种非常浅的整合方式呢？当然是有的。

实际上，无论是CesiumJS还是类似ThreeJS，他们底层目前都是基于WebGL/WebGL2绘制到Canvas来实现的（WebGPU还远没有成熟），那么我们是不是可以直接在一个Canvas让CesiumJS先画，ThreeJS后画呢？答案显然是可以的。但是我们依然会面临非常多的整合问题和技术难关，这个我在后面的系列文章中会逐一给大家解释。