真正用起来,二维比三维更重要

简介: 今天这篇文章起这个标题似乎有点逆潮流,但是这确实是开发的表达,同时也是我这两天和开发交流之后最直接的感受,当然这个开发的群体是有一定的限定的,就是时空大数据的开发团队主管,但是这些经验对于建设其他数字孪生类的应有也有着很好的借鉴和参考意义。(本人工作于交通行业,现在本人单位也在建设数字孪生相关内容,有感而发故此想谈谈感受)

二维数据比三维数据重要

1、2D是基础、3D是锦上添花,从城市存量的角度来看,目前城市大量的存量数据还是以2D为主,数据的更新机制、技术体系、以及应用机制也比较成熟,所以如何将2D数据管理好、共享好、应用好,就可以满足城市智慧化应用中绝大多数的问题,同时现在大多数应用的很好的系统中其实使用的还是2D或者是2D+(包括白模和2.5D切片)的数据,大部分使用真三维数据的系统反而使用情况并不理想,包括成本、体验都还有不成熟的地方。

2、2D才是数据载体,空间数据除了本身的空间信息表达,在城市信息化系统中还有一个作用就是作为数据载体而存在,在不同的业务系统中,可能使用了一套空间数据,但是空间对象上关联的业务信息却是不一样的,而根据现在的技术方案,无论是倾斜三维、2D还是2.5D的数据类型,其数据挂接的信息还是通过2D对象来完成的,比如倾斜的对象信息是最简单和快捷的方式就是通过2D的几何到3D Mesh的贴面来完成的,所以即使是3D的「形」,但是背后对业务的支撑还是需要依赖二维的实体对象来完成,所以这个2D的实体是根本。

3、三维涉密,现在还是擦边,这个前面的文章都介绍过,由于涉密的限制,其实现在实景三维做了也只能受制于环境趴在内部的环境上,即使经过脱密发布在政务网其实也还是属于灰色地带,只能低调使用,更不要说发不到互联网了,这个部分还需要等政策明朗之后才会能够得到改善。

实体扩展比图形升维重要

根据《地理实体数据规范》的定义,地理实体 GeoEntity是指:「现实世界中独立存在、可以唯一性标识的自然或人工地物」,其实按照现在流行的说法就是在逻辑上将客观的「物理实体」孪生化为「数字实体」,而在城市各种数字化的应用对空间数据的集成更多的就是要将各自领域的业务对象关联到空间对象,从而实现地理实体在语义上的扩展,实现从单纯的地理实体升维为城市信息实体,这些实体关联的信息越多相应的应用价值也就越高。

所以从价值密度上来看,城市孪生的主要发力方向应该是考虑如何提升地理实体的扩展以及信息密度,比如进行跨部门的数据打通和协同,但是现在城市孪生的重点更多的是研究如何对空间图形的升维,把空间对象做的更精细,但是这种精细的升级如果缺乏必要的实体扩展和其他城市城市信息的挂接,则在价值上就会略显单薄,应用价值有限。

简单来说,实体扩展的过程就是各个部门用地图根据需要在地图的对象上进行数据的挂接,挂数据的过程其实就建立了唯一的空间对象与其他业务对象的关联关系,即使数据是分散管理的,但是如果这个实体的ID是统一的,则后续数据的聚合则成为可能。

这个逻辑其实放在CIM以及数字孪生城市中是一样的成立的,比如现在CIM强调的「规、建、管、运、服」全生命周期的串联,如果没有形成这样基础的ID体系,这个目标也只能是空谈。

ID关联比地址匹配更重要

One ID的体系建立其实目前主要分为两种模式:「事中的关联」「事后的关联」

1、「事中的关联」是指在业务发生的过程中,二者的ID通过业务系统就已经建立好关联关系了,比如社会治理在进行人口的挂接的时候就明确选择了相应的空间实体对象,并且保存了一份人口ID或者房屋ID与空间实体对象的关联关系,这种模式就不会存在后续重新挂接的问题,但是由于过去地理空间服务大多都是直接使用切片服务,大多数和业务还是保持「两张皮」,而当前的客户在一开始就提供了实体服务,这样一来,这个目标则成为了可能。

2、「事后的关联」是指在在业务过程并没有直接建立起相应的ID关系,而是需要依赖后期数据治理的手段来进一步进行数据的关联,现在看的比较多的方法主要是期望依赖地名地址的关联以及重新的手工挂接,但是这两种都存在一定的限制,期待地址匹配的就要需要双方的数据都具备标准地址字段才可以进行,而且存在一定的不确定性,如果这些数据都缺乏则只能依靠后期的手工挂接,这个还需要借助一定的核实的手段,成本比较高。

现在市面上很多关于数据治理的书籍和产品更多的是从事后治理的角度来谈,但是这种事后治理的思路是不是一定适用于城市空间数据这个场景,这个目前是存疑的,真正的数据治理还是要依赖业务的系统才可以真正实现,这是本质,避开根本问题,单纯的讨论是不现实的。

协同比治理重要

当前交流的客户在这个方面做的很好的原因在于,当前的客户在其城市,在业务上事实上已经建立起了一个「One Map」的体系,当前城市的所有部门都是基于测绘部门的这张地图,比如针对建筑实体,其从源头的「规划到房管、到不动产登记、到社会治理、到测绘年度更新」,各个部门都在一个空间对象上进行业务的完善,这是一个非常完整的业务和技术流程,而且这个过程地图服务都有相应的实体化服务配套,实体化服务背后其实就是One ID体系的保证。

而这个协同的过程也是真正的做到了「源头共建、协同共治」,协同其实并不是代表大包大揽,协同更多的意味着边界明确。

边界比理想重要

数权也是事权,动别人的数据也是动别人的业务,手伸的太长就会导致部门间的矛盾激化,更多的还是要做好自己的事情。

比如测绘部门其实放在整个政府的信息化体系下其实也是一个服务的角色,只要为别的部门提供更好用的一张图,如果测绘部门主动服务的意识强,则测绘部门的数据和产品触达的能力就会很强,但是如果测绘部门没有很好的服务意识,则相应城市空间的碎片化程度就会比较严重。

比如当前的客户,他们不仅把地理实体以及业务协同做的很好,还承担了其他部门关于地址以及地名的系统开发项目,这样一来,其他部门制作的一手的地名地址数据也都在这个部门了,他们还有计划将这些数据共享给其他的物流和图商使用,提高他们的数据质量,从而提升对当地的服务能力,但是我们同样发现有的一些地方主管部门的地名地址数据质量很差,自己还要向图商或者物流公司购买,这是两种非常不同的情况。

其实明确好边界也就是明确好职责,不能只让别人配合你,这样太理想了,更多的还是要双赢。

相关文章
|
8月前
|
算法 前端开发
三维形体投影面积
三维形体投影面积
36 0
二维坐标系空间变换(详细解读,附MATLAB代码)
二维坐标系空间变换(详细解读,附MATLAB代码)
611 0
二维坐标系空间变换(详细解读,附MATLAB代码)
|
定位技术
ArcGIS:如何对栅格图像进行地理配准和定义投影?
ArcGIS:如何对栅格图像进行地理配准和定义投影?
1181 0
|
Python
点云在任意平面上获取二维投影
点云在任意平面上获取二维投影
1027 0
点云在任意平面上获取二维投影
|
数据可视化 API
|
传感器 算法 前端开发
【应用SLAM技术建立二维栅格化地图】
【应用SLAM技术建立二维栅格化地图】
356 0
|
算法 图形学
【计算机图形学】实验三:二维图形变换
【计算机图形学】实验三:二维图形变换
195 0
【计算机图形学】实验三:二维图形变换
|
算法
LeetCode——883. 三维形体投影面积
LeetCode——883. 三维形体投影面积
93 0
LeetCode——883. 三维形体投影面积
每日一题—— 三维形体投影面积
每日一题—— 三维形体投影面积
89 0
每日一题—— 三维形体投影面积
四元数与三维旋转
四元数与三维旋转
125 0
四元数与三维旋转