bim名词解释，7条BIM运维之痛：老法师从「OpenBIM」聊到「noBIM」

你好，这里是。

今天是一位老朋友的分享，上海水石建筑规划设计股份有限公司 BIM 中心负责人，大名金戈，网名铁马。

圈子里聊起BIM和运维，我们总是第一时间想到他，作为从业20年的老法师bim名词解释，和一名坚定的「数据BIM」布道者，他不仅专注技术与思想的研究，也给大家带来过不少关于BIM数据应用、BIM运维的干货分享，还自己开发了一款基于BIM的免费数据管理软件。

最近，金戈又写了一篇长文，专门给BOX的小伙伴们分享，他这些年为各种业主提供的服务之中，用BIM做运维的7个痛点，也非常实在地讲述了哪些痛点有解决方案，哪些痛点还是当前行业的发展掣肘。

搞清楚这些问题，我们才可能把这件事做得更好。内容量很大，读完一定有收获。

下面是经过BOX修改的、金戈的分享。

和的技术陷阱

坊间有两个术语：「」和「」。

所谓「」，指利用IFC格式进行数据交互的BIM应用。

所谓「」，指利用某个单独的商业软件（比如）进行数据交互的BIM应用。

这两者有一个通病，就是需要把数据直接加载到模型中，然后利用这个富含数据的模型文件进行应用。而这会存在三个潜在的风险。

➤ 第一个问题是数据处理。

当前的技术在处理三维模型时，依然存在很多问题，比如流畅度、美观度等。加载数据后，只会加重计算机的处理负担。并且应用程序需要穿透模型文件之后，才能应用数据，这更会增加难度。

➤ 第二个问题是数据共享。

就算是欧特克公司自己的其他软件产品，在读取保存的文件时，都会出现数据丢失的问题，更不要说其他软件。

➤ 第三个特别重要的问题是数据归档。

当以某个软件格式存储数据的时候，一旦出软件停用或公司停止服务，就会出现无法读取的重大问题。如果文件遗失或损坏，那就是连带着数据一起遗失。

什么是？

美国公司「SMRT AND 」纽约办公室的主任John ，在一篇文章中提出这个概念：没有模型的BIM数据。大概的意思是数据的交互应该基于数据库，而不是基于模型。

美国的 E 写的《大BIM4：连接世界的生态》，可能是唯一一本不谈模型的BIM著作。这本书提倡的概念，是将围绕着模型文件的应用，称为「小bim」，而基于系统的应用，称为「大BIM」。

另外，这份标准中提到的通用数据环境（CDE），主要就是解决BIM数据的传输和共享。

在国内，很多人经常提到「数模分离」，我也多次在文章中讲过，意思也是数据和模型分开存储并应用。

以上种种，我们姑且统称为「」，本质上就是依托数据库对建筑数据进行清洗、存储和管理，从而实现建筑数据的共享。

在应用层面依然有模型的存在，但是骨子里其实是数据驱动，而非模型。

图片来源《没有模型的BIM数据》

最极端的情况是，数据本身存储在数据库中，甚至连模型也是基于数据库进行存储，可以根据用户的需求，转化为任意三维格式，而不是以某种固定格式存储。

我认为，是对BIM的高阶应用，也是未来的一个趋势。是从以模型文件应用，向构件转变，进而从构件向数据应用的转变。

那么，，和和运维有什么关系呢？我们把这个话题暂且放下，先聊聊我的运维服务工作思考。

什么是BIM运维？

从2015年经手第一个BIM运维项目开始，我一直在思考：BIM和运维是什么关系？

这个问题拆分成几个子问题：

➤ 没有BIM的运维是什么样的？

➤ BIM为什么需要运维？

➤运维为什么需要BIM？

慢慢的，网上开始有一些BIM运维案例，但是除了模型的可视化之外，我没有看出来BIM运维平台有什么特别的价值。

尤其是当我尝试在点击各个功能时，把模型遮住，发现对功能并没有什么影响。换句话说，即使没有模型，这些运维功能也是可以跑通的。

那BIM存在的意义是什么呢？或者换一个角度来说，BIM存在的意义不是解决业务功能，是解决别的什么问题？

在探索过程中，两句话点醒了我：「数据是企业未来重要的资产」，还有「数据即服务」。

所谓BIM运维，并不是说用BIM来做运维的业务，而是提供一种基于数据的服务。

传统的运维解决的是业务流程方面的服务，例如维修维保、安防管理、设备管理等，而BIM运维是传统建筑运维的升级版，增加了数据管理的功能。

基于模型的三维可视化，只是数据管理的一个子项功能，但是这个子项有点喧宾夺主了。

简单来说，BIM运维=业务模块+数据模块。

接下来还有一个问题需要解决，传统的建筑运维在升级的时候，为什么一定需要BIM技术呢？有没有可能是别的技术？

很抱歉，暂时没有，BIM是唯一的选择。具体原因老孙已经在这篇文章里探讨过了：

如何实施BIM运维

理清楚了什么是BIM运维，接下来就是要解决怎么实现的问题。

下面和你聊聊我在近10年BIM运维服务过程中，遇到的7个真实痛点。

1.需求之痛

目前从事BIM运维的，大部分都不是运维这个行业的人，对运维需求都不了解。

一个很有意思的情况就是，在BIM运维这件事上，甲方、乙方、第三方，都说不清需求是什么——负责人说不清需要什么，懂需求的人说不上话、或者不会总结需求。

这也是大量BIM运维项目失败的主要原因：为了上系统而上系统，不是为了解决某个需求而上。

我们做BIM运维，就是借助建筑数字化的技术，在不降低传统运维的质量下，达到降本增效。传统的运维主要包括以下工作方向：

➤ 物业管理：包括维修维保、保安保洁等；

➤ 资产管理：包括施设备、备品备料等；

➤ 空间管理：包括公空间、租赁空间等；

➤ 安全管理：包括应急、消防、报警等；

➤ 能源管理：包括用水用电用气等。

下面这张图是运维大神梳理的业务功能。

既然要降本增效，就需要从成本的角度来分析。就成本来说基本上可以整合成这几个维度：人力成本、能耗成本、设备成本、维护成本、其他成本。

很多客户找我们，第一句话就说，我们要上一个运维系统。其实没有一个运维系统能包打天下的，因为根据不同业态的特性，成本的占比各不相同，需要解决的问题也不同，需要一事一议。

例如住宅项目，设备比较少、人员比较多，人力成本占比较大。那么这种业态的运维，就需要考虑如何有效的减少人力成本。而工业项目，设备能耗是大头，就需要考虑如何有效的节能。

2.架构之痛

我曾经在一家施工总包单位工作过近5年。当时行业内兴起各种项目管理平台，或者叫BIM协同平台。

大部分人理想中的平台，都是包含了工程建设的各个要素，既要有八大员，又要有人机料环法，还要有进度质量安全等等。

可我看到，有些公司好不容易赚到一点钱，都投进去开发平台，活活累死一大批。我们当年是测评了市场上各类软件工具，然后根据项目需求来组合。从来没有一个包打天下的大平台。

其实BIM运维平台也一样。一提起它，业内人士脑海中浮现出来的通常是个很炫酷的、基于三维模型的软件平台。

我们接触到的一些BIM运维平台，有这么几个特征：

➤大部分基于游戏引擎，核心是做漂亮的三维展示；

➤需要大量定制的工作；

➤ 价格昂贵，几乎都是百万级；

➤有一些统计功能，却很少有数据管理功能；

➤无法衡量投入的收益。

从某种程度来说，现在大部分BIM运维项目还是处于探索阶段。

而基于我们对BIM运维平台的理解和实践，BIM运维平台=CDE软件+IOT软件+物管软件+数据软件。

BIM运维平台不是一个软件，应该是实现多个功能的一组软件集合。

我在前面提到了「BIM运维=业务模块+数据模块。」基于这个逻辑，可以把它拆分成下面的架构：

业务模块负责物业管理、资产管理、空间管理、安全管理等，数据模块则包含解决工程数据的CDE、解决动态数据的物联模块，以及解决数据清洗、存储、管理和共享的数据平台。

关于业务模块和物联模块，大家基本都共识，在我的理解中，CDE模块主要解决的是BIM数据在线和共享的问题，比如我们自主开发的就可以是一款CDE软件。

相比CDE，数据平台则要解决多种数据的在线和共享问题。现在有很多这样的产品，有数据仓库，有数据中台，不管叫什么，功能都差不多。

图片来源「」

3.实施之痛

知道了BIM运维需要做哪些事，接下来就是评估自身能力，能做哪些？不能做哪些？

基于前面多软件组合的共识，我认为实施BIM运维需要以下知识和经验：

➤针对CDE软件，需要BIM知识、引擎知识、IT开发知识；

➤针对物联模块，需要弱电智能化知识、IT开发知识；

➤ 针对业务模块，需要物业管理经验、IT开发知识；

➤针对数据平台，需要数据管理知识、数据库技术等。

可想而知，具备以上所有知识的团队凤毛麟角，所以大部分项目都需要跨团队协作。

根据我们的调研，市场上主要有这么几类公司在做BIM运维。

➤ BIM咨询公司升级。

比如设计院和施工单位独立出来的数字公司，或者第三方BIM顾问，包括我们水石设计在内，也都属于这个方阵。

这个方阵的优势在于懂建筑行业、懂BIM、懂模型创建；不足在于物业知识较弱，数据对接和管理较弱，IT基础比较薄弱，团队稳定性也比较差。

➤ 三维可视化公司升级。

主要是GIS起家、三维引擎起家的软件科技公司，还有一些专门做展示大屏的公司。这类公司的特点是有一定的IT开发能力，能迅速交付一个平台，让业主眼前一亮。但是缺少物管知识，以及对BIM数据管理能力，产品功能较弱。

➤ 智能化服务升级。

主要是以前专门从事智能化服务的公司，比如楼宇自控、能源服务、实验室和机房等服务，做业务升级。这类公司IT知识相对丰富、智能化业务逻辑清晰、稳定性高。但是物业业务逻辑较差，BIM和三维引擎的应用比较差。

➤ 传统运维公司升级。

主要是传统五大行和一些物业公司的业务升级。这类公司的物管经验是最丰富的，也会引入三维引擎。但是缺少IT知识，特别是缺乏对BIM数据的应用，对BIM的理解还停留在展示阶段。

➤ 第三方跨界。

这部分主要是一些大厂，从工业、金融、互联网等圈子跨界到运维中来。这类公司的特点是资金雄厚，可以快速整合各类资源。不足是对建筑行业不够了解，物管能力和经验缺乏。通常是资金驱动或IT驱动，而不是需求驱动，导致产品很难落地。

所以你看，在复杂的运维服务面前，每一方都有自己的缺陷bim名词解释，7条BIM运维之痛：老法师从「OpenBIM」聊到「noBIM」，合作才是当下比较可执行的方向。

所有认真做过BIM运维项目的同行都会认同：一个BIM运维项目，平台开发占一半，实施占一半，甚至更多。一个团队的实施能力几乎可以决定了一个BIM运维项目的成败。

对我们团队来说也一样，我们最缺的是IT和数据库方面的知识，也不回避这些短板，每个项目都在合作中不停去学习和进步。

4.引擎之痛

现在国内做轻量化引擎的公司很多，主要是类似U3D的线下技术，或这样的线上技术。

我发现在运维阶段，很多公司还是采用线下的游戏引擎来展示，其实并不是一个很好的选择。

游戏引擎的好处显而易见，很多开发公司用起来相对熟悉，而且展示效果也更好看。但是最大的问题就是，当BIM模型传递给它时，相当于把丰富的数据格式化了，只剩下一个壳子了。

这导致很多业主对引擎的理解都停留在可视化，这是行业的可悲。

真正的引擎，应该能完整继承BIM模型中的各类数据，并准确地展示出来。

另一方面，在线技术的引擎也有问题，就是模型承载量相对有限，容易出现崩溃。

所以，综合起来的现状就是：游戏引擎漂亮、稳定，成本高，缺乏数据联动；在线引擎数据量有限，稳定性略差，成本低，可以进行有效的数据联动。

目前要破解这一对矛盾，从技术角度来说，我见到了两个发展方向。

➤第一是开发超级引擎，可以流畅的跑各类超大模型。我见过这样的引擎，不过暂时没有公开推广。

➤第二是开发基于LOD的引擎，对模型的展示分多个精细度。在视线中的模型高精度展示，离视线远的模型用低精细度展示，以此来降低数据量，达到流畅展示。

这方面的发展很快，也总有新的方案出现，比如 、、国内很多低代码引擎等等，大家都可以多去关注。

对于我们这种非IT人员，也没有开发超级引擎的能力，解决问题的思路是从逻辑出发，而不是从IT技术出发。倾向于使用LOD的方案，降低数据量，保证局部模型的精细和数据完整度。初步的方案是：用二维地图代替，用白模代替，用实景模型代替，用BIM模型。

5.模型之痛

很遗憾，国内很少有团队具备BIM运维模型的创建能力。

当然也可以说，运维模型的要求太高了，导致投入产出的不对等，所以也没有太多的团队愿意做这件事。

我找了很多业内的大佬请教，得到的普遍反馈是，运维模型这件事很鸡肋，价值是有的，但是付出的代价有点太大。

简单说几个运维模型和常规建设模型的区别，你感受一下：

➤ 一般设计模型专注如何出图，施工模型专注如何指导施工，而运维模型专注后续运维使用。比如运维模型非常注重拓扑关系，而大部分建模工作不会花时间做真实的连接，反正设计施工也用不着，运维阶段光是弥补这一点就需要大量的时间。

➤ 建设阶段的模型主要关注设备和管线安装，而运维阶段除了设备管理需要，更多的是对弱电系统的应用。比如各种弱电设备、摄像头、插座、道闸、电柜等，这些都不是重点建模，甚至很多是不建模的。

➤ 建设阶段的模型主要面向设备和土建施工，会忽视对空间模型的创建。在运维阶段，空间则是作为重要的资产需要被管理。

这几条是运维模型特别需要关注的几个点，退一步说，撇开这几点，很多竣工模型也是差强人意。

现在有多地方政府要求交付竣工模型，但是这些模型确实质量堪忧，能带来复利价值的凤毛麟角。

再举一些例子，模型质量的差体现在这些方面：

➤构件缺失，各种阀门、管件、软接等等基本没有。

➤系统错乱，比如雨水排水、生活排水、生产排水、空调水等等。

➤ 设备错放，比如水管上需要接管道泵，可能就随意放了离心泵。

➤ 不合理的对接，比如20管径的空调水管，接了水泵直接变径到50。

这些稀奇古怪的错误，真的非常让人很崩溃。曾经有一个BIM大赛，我检查了将近50个参赛模型水泵房的设备情况，只有寥寥几个项目做了正确的连接，模型质量之差，让我瞠目结舌。

这可能也是BIM经常被人诟病的原因吧，我非常希望今后随着行业的发展、甲方需求的明确，这种情况能有所改善。

6.标识之痛

现在BIM模型的主要用途在于出图和指导施工，这个过程中，标识的重要性往往被大量的忽视，比如构件标识、系统标识、空间标识等等。

这也是BIM模型区别于传统三维模型的重要元素。

我们经常在看到这样的分享：运维中出现漏水，利用BIM模型，可以快速排查是哪个阀门出现了问题，从而提高管理效率。

那么，如何实现呢？要知道，到了运维阶段，管理人员面对海量的房间和构件，已经不可能通过轴网、坐标等数据来实现定位了。

如果只是把模型扔到某个引擎或BIM运维平台，对不起，无法实现，或者说需要大量的人工挂接。

而只有在模型中做了足够的标识工作，才能让模型发挥出它的作用，标识对于模型，就像瞄准镜对于狙击枪一样重要。

这些标识在模型中是天然存在的，但是不足以表达清楚关联关系，需要建模人员做一定的优化。

在我们实际接触的项目中，这项工作需要后期大量的人力去弥补。比如我们会要求在所有构件加上设计编号字段，设备构件里添加所属房间号，部分构件添加轴网坐标等。

7.编码之痛

《BIM 》这本书里有很生动的解释：编码，是解决不同系统对同一构件的称呼问题。

类似人的身份证号，既需要唯一，又需要能方便扩容。

国标虽然已经发布了分类编码标准，也是引用自国外的标准，但是不具备很好的落地性。

曾经发过一系列编码的科普文章，我也在里面贡献了一些内容，你可以去了解一下，编码的名词解释和重要性这里就不重复了，在这重点说一下编码的逻辑，简单来说要有以下五个特征：

➤能唯一性的表述一类设施设备；

➤具备无限的扩容性；

➤ 方便识别的精简性；

➤ 和数据字典关联的灵活性；

➤ 实施的便利性。

比如，身份证号基本上代表了编码的极致，前六位代表所在地，中间8位是出生日期，后面4位是流水号，只留下最精简的信息，有很好的唯一性、扩容性和精简性。

身份证号有两个显著的特点，一是随着孩子出生就生成了；二是只保留最基本的识别信息，没有人物特征信息。这两点特别重要。

再看第二个案例，这是一个实际项目的设备编码，有27位，包括了位置、系统和设备信息。

很多公司喜欢把编码弄的无比完整，恨不得包含所有信息。这其实是对编码和数据的误解，编码信息并不是越丰富越好。

编码是给计算机用的，不是给人用，是为了保证构件的唯一身份可以在不同系统中进行数据交互。你进一步想知道更丰富的信息，通过数据检索就能查询到。

有一个难点在于，和人类的身份证号一样，最好的编码应该是在设备诞生的时候，就能生成，工程中对应的就是初步设计阶段，并且在整个项目中一直跟随这个设备，才能实现所谓的数据复用。

但要实现这一点并不容易。

比如一台风机，编码中包含设备的类型，如果开始是一个离心风机，后来变更为轴流风机，那这个编码也要跟着变，这个工作量就太大了。妥协的方法是在竣工阶段去编码，那就失去了建设过程中的应用价值了。

经过这么多年的实战，我们认为一个好的编码标准，大概是：设备编码=限定编码+分类编码+流水号。

其中，限定编码一般区分最基本的项目、单体或楼层，分类编码区分到类别就够了。

目前，我们的分类编码标准在网页端已经公开，大家既可以直接免费使用，也可以在我们的基础上做修改后再使用。其次，我们在上，单独开发了一个可以灵活配置编码规则的模块，不同公司、不同项目，可以根据自己的需要进行配置，再一键加载到模型构件上。

8.数据之痛

模型缺少数据，这是运维行业看待BIM的一种共识，这里既包括模型非几何数据的大量缺失，也包括数据标准的缺失。

后者在行业里又被称做「数据字典」，这方面可以参考，它是美国最重要的两个数据标准之一。目前国内已经有一些行业数据交付要求，特别是数字化比较深入的基础设施行业和制造业，建筑业可以参考。

我们今天要聊的数据，主要是BIM应用过程中，模型产生并需要关联的数据，一般我们称之为静态数据。里面包含了很多内容，就我们目前的认知，可以从提炼使用的数据，包含下面这些：

➤ 几何数据

比如设备的长、宽、高、标高等，以模型自带为主。

➤ 空间数据

包括房间或公共空间的面积、名称、归属等，以模型自带为主。

➤ 编码数据

比如构件ID，可以是模型自带的，但一般都是用户根据项目需要自己赋予编码。

➤ 工程数据

包括设计、施工和运维相关的数据，比如设计参数、施工人员、产品厂家等，一般都是用户赋予。

➤ 关系数据

包括设备的风、水系等统关系和空间关系等，以模型自带为主，也可以根据需要进行调整。

对于的学习，我一直对团队的要求是，一定要掰开揉碎研究细节功能，每一个功能都点击过，使用过，知道使用后的效果。

对于数据使用，首先要知道有哪些数据，哪些有用、哪些没用、哪些需要挖掘。带着这些问题，我从家具模型、结构模型、管道模型、设备模型等等角度，利用我们的数据管理软件把所有的属性提炼出来研究。

下面的图是家具族的属性，其中蓝色标注的ID、楼层、房间、类别是有价值的运维属性。

再比如一个管道的属性，其中蓝色标注的ID、楼层、直径、长度、系统类型是有价值的运维属性。

类似的，还有结构模型的体积、厚度、面积，设备属性的系统名称、系统分类等等。

这些数据基本上体现了构件的基本特性：我是谁，我的身份，我的重量，我的身高，我在哪里，我属于哪个系统等。有了这些数据，就可以做很多事情。包括工程量统计、包括设备维修的拓扑关系等等。

此外，还有大量的工程数据，是需要我们在项目实施过程进行收集的，结合地铁、国网以及国标，将所有的工程数据分成了图上的9大类：

需要做竣工模型或运维模型的项目，都可以直接到平台上，给相关的构件批量的加载这些字段。另外我们还在平台里内嵌了上海浦东交付标准、深圳工务署交付标准和深圳地铁交付标准等。

以上就是我总结的8点BIM运维之痛，和截止到目前我的方案与思考。聊完这些，我们可以回到一开始谈到的「」了。

总结：与数字化交付

经常有人问我，怎样在模型上加载他们需要的数据，也包括数据的排序、类别等各种技术问题。

我经常的建议是：不要这么做。

数据可以放在数据库里，或者最不济的，可以放在表里。因为最终，所有数据都会在软件系统中被使用，最终还是要进数据库的，那么之前做的各种基于模型加载的东西，都会是无用功。

如果是依据「」的理念，从项目的开始，就需要一套软件系统全程陪同，模型在设计软件完成更新，而数据在云端更新。最后数据库对接数据库，完成数据交付到运维平台。

图片来源「」

基于「」理念，我们服务了很多业主客户，搭建企业级的BIM运维平台，来实现企业数字资产管理和数字化转型。

回过头来看，有两件事很有意思。

➤ 第一，经常有客户和朋友问我们选什么软件。

而我的建议一般是：BIM建模软件一般分为专业和通用两种。专业软件能更好的解决某一个方向的问题，但是数据传递性较差，例如。通用的软件则是专业功能一般，但是数据传递性更好，例如。

为了保证竣工交付，我一般会建议用通用性更好的软件。但是，现在来看，这似乎是一个不完备的建议，至少得看项目情况。

原因在于，我们经历过这么多的BIM项目，发现凡是没有企业规划的BIM模型，运维阶段都没办法使用，为了修正这些模型而投入的资源，足够重新建一个了。

所以，如果甲乙双方对数据该怎么用这件事压根没想清楚、也没约定清楚，与其用通用软件做一个交付了也没有价值的模型，还不如直接用专业软件，好好的把建设过程的价值发挥到最大。

➤ 第二，只有那些业主自持、且有一定体量的项目，做数字化交付有意义。

前面我们说了这么多，搭建一个合格的BIM运维平台，要花费大量的资源，而能支撑这些资源的回报，必须有后续大量的数据应用。一般销售型的项目这方面不会有太大发挥，而体量比较小的单一项目，就算自持，也没有足够的数据样板。

在很多年前，我就一直坚信BIM的未来一定是「数据为王」。BIM运维的成功一定离不开两个支撑：一是技术，二是数据。

技术可以赋予BIM运维各种可能，而数据却是这些可能成真的底座。技术在建筑信息化这个领域其实已经有了长足的发展，而数据始终不够被重视。

无论怎么说，这些作为我的本行，都不是在给大家泼冷水，只有我们把问题提出来、直面它们，才可能有行动和探索的方向，我相信未来有了足够真实有效的数据，BIM运维一定能开出绚烂之花。

bim属性栏怎么调出来，bim怎么把属性调回原来的样子 bim左边属性栏怎么变小？

bim左边属性栏怎么变小？

详细先添加方法万分感谢：

1、必须可以找到你要添加的命令，单击鼠标右键，右键单击直接添加到快速访问工具栏。

2、完成后bim属性栏怎么调出来，此命令就被直接添加到快速访问工具栏了。

3、虽然的，如果不想这个命令了，右键–从快速访问工具栏中调出了。

4、成功后，此命令就从快速访问工具栏调出变小了

bim怎么更改ip？

不过在此之前，我们先找不到网络，再点它。

2/

5第二步，比如找不到共享文件夹中心直接点击它。在不能找到本地链接，单机它。

3/

5第三步，不能找到属性这项功能，单机它。

4/

5第四步，我们找到协议版本4（TCR/IPv4），并且右击它，并可先打开如何修改选项。

5/

5第五步，我们选择（在用下面的Ip地址），然后把并且改。

bim作业id怎么改？

改bim作业id不过在此之前，我们先找不到网络，点击它。

2/

5第二步，其次不能找到共享网络中心再点击它。在找不到本地链接bim属性栏怎么调出来，bim怎么把属性调回原来的样子 bim左边属性栏怎么变小？，单机它。

3/

5第三步，能找到属性这项功能，单机它。

4/

5第四步，我们可以找到协议版本4（TCR/IPv4），因此右键点击它，并可打开直接修改选项。

5/5第五步，我们你选择（不使用下面的Ip地址），接着参与你要改。

bim标注文字怎样换位置？

bim标住文字换位置步骤万分感谢，

必须在BIM软件中，

单击门窗，变会不自动显示其两侧的上标，

可是其尺寸标注边界在系统设置为时是从墙面层又开始标示，简单的方法右键单击【管理】面板中的【其他设置】，

在提示框的下拉选项中找不到【正式标注尺寸】这个选项。单击之后，会自动弹出”原先工程图属性“的对话框，在这边接受修改就可以了。

bim怎么调出属性栏？

bim菜单属性栏方法：

1.简单的方法，再打开，改扩建项目文件，点击属性窗口和项目浏览器右上方的“X”符号将它们关闭。

2.排列然后点击视图-用户界面，主菜单下拉框，在属性和项目浏览器前面的方形你选择框中打“√”，就这个可以。

3.我们还可以不在绘图区空白处，再点击右键，再点击项目浏览器然后点击属性，同时可以调出项目浏览器和属性窗口。