地理空间与三维有机结合

最新推荐文章于 2025-09-11 10:05:49 发布

原创最新推荐文章于 2025-09-11 10:05:49 发布 · 217 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#javascript #前端

本文探讨了在地图项目中平面、2.5D和3D结合的问题，指出平面地图和2.5D的常见应用场景。作者提到3D虽然炫酷，但在地理信息融合方面存在挑战。通过思考和实践，作者发现Mars3D为解决地图与模型结合提供了可能，并提供了项目实例和前端技术栈的总结。

摘要

地图相关的项目和实践绝大多数超脱不了一个问题,平面、2.5D、3D的结合部分处理,裸3D的实践意义不强,通常是定制性的，不具备可以移植性,而平面和2.5D的又常常超脱不了平庸的定式,本次说说3种模式的有机结合,及解决过程种的问题及办法。

问题

通常项目中的精细化实践中常常会用到平面地图,我们平时所见的系统也绝大多数为此类，多为功能性的，如点标记、信息交互、缩放聚合、线路径标记,轨迹动画等等。

地图服务如我们常用的百度地图、高德地图、腾讯地图、goolge地图，通常会有配套的地图服务及端组件提供,再者如OpenLayer、Turf等模块化的GIS引擎。高德地图
app 这个应该大家都不陌生,打车软件、共享模式下各种类似的应用层出不穷,功能性多以轨迹、范围、车辆位置标记为主
系统应用如设备、物流、工业、销售或者医疗、或者是商场等涉及区域地理相关分布的,绝大多数为了便于直观的对数据进行检索,多会具备此项功能。

大屏/数字孪生
孪生,往往因为精度与地理不匹配沦为示意图或者炫酷门脸工具，失去了实际应用价值，一方面建模不具移植性，且精细化成本过高,带来的实际价值无法和应用结合,处境有点儿尴尬。
最常规的估计就是飞线图,也多示意图性质居多一些,制约的往往是数据的支撑达不到经典的echarts可以达成很多效果

平面、2.5D

此类的应用对于应用系统来说,从10年前到现在的打磨,各式各样的效果,交互组件层出不穷,像是地图的视口倾斜渲染图层伪2.5D显示等等,从职能上来说其实没啥本质的提升,基本上是原地打转

3D

此类各种炫酷的交互，呈现treejs的各种模式，好像天然的把地理信息和3D进行了人为的隔离，可能数字孪生的诉求里面根本就没有拉跨的2维地图的一席之地,最终炫酷的追求炫酷，实际的追求实际，给人造成的误解就是孪生就是绝对的还原真实,但往往是以示意图呈现的真实，最终数字孪生的应用效果变得很尬尴，更像是迎合口味的一种操作。

思考

之所以会思考，本质上还是因为被折腾的焦头烂额的,因为项目地图做的居多,更注重的是落地和实施可能性，不可能费了天大的功夫,最终被种种技术风险和无理的诉求打爆，但这个事儿还是得去有个思路去解决，如果你经历过（非技术性驱动的公司）应该能体会，本质上是支持常规的地理信息，同时能对模型，细化的矢量图进行结合及渲染,才可能具备双方都满意的结果，现在越来越发现找组件是个随缘过程,只有坚持不懈不停找，才能找到合适的东西

先上效果

总结

技术栈支持Vue、React、js算是调用及样例都比较全面,算是半开源,某些特殊功能需要比较多的空间服务支持，此项服务应该是需要授权或者自己开发的 <img src=“https://p1-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/5ee7377db3434e278bb114608410c5e7~tplv-k3u1fbpfcp-zoom-in-crop-mark:4536:0:0:0.image?) 根据其前端的部分代码，感觉有点儿趋近于超图的某些图层瓦片化处理,多半会有比较厚重的服务支撑，但常规的前端部分实现是以开源组件形式提供的项目实例 ![image.png](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/60a684d6a8084ecb86fa62f40139d567~tplv-k3u1fbpfcp-zoom-in-crop-mark:4536:0:0:0.image?” style=“margin: auto” />

最后

实践出真知,往往技术选型先看其能达成的最高效果是否与自身的诉求满足，如果能满足今后的扩展诉求更好,接着就是踩坑实践了,而我们得出最终结论是以模拟实现某些功能，具体进行操作,技术实践没啥解决不了的问题为准,因为临近年关，没啥精力跑代码给出具体的实践分析，希望感兴趣的老铁也能分享具体项目中的问题及槽点，以作后期的探索。

临近年关，没啥精力跑代码给出具体的实践分析，希望感兴趣的老铁也能分享具体项目中的问题及槽点，以作后期的探索。