一张楼盘表,半部房产管理发展史
- 2026-01-09 06:53:00
楼盘表，顾名思义，是以单个楼幢为单位绘制的【户室地图】，通过一张清晰的二维表格，将全部户室信息尽收眼底，让全局规划与个体单元的关系一目了然。
你可能从未留意，但它其实与我们每个人的生活息息相关。比如，你是否曾好奇邻居家的户型是怎样的？同一楼层中，不同面积、朝向甚至价格的分布如何？这些信息，都静静躺在那张楼盘表里。
对于管理者而言，楼盘表更是不可或缺的工具。楼盘管理者依靠它统筹全部户室状态；开发商借助它制定房价、掌握销售进度；相关管理部门则通过楼盘表高效核验数据、办理登记业务——一张表，串联起从建设到管理的全流程。
一楼一故事
图：某房屋楼盘表
这是一张楼盘表。乍看之下，你可能会觉得这幢房子里边的户室号信息有些混乱，并对其排布感到困惑：为什么有两个101室？为什么有些编号方式显得不太符合当下的常规，而某几户却符合我们熟悉的门牌命名规则？
仔细看，你可能会发现一些规律（见下图），这是怎么一回事？
图：某房屋楼盘表命名规律
上个世纪60年代，在南京长江大桥建设过程中，建设单位为解决建桥职工的住房问题，经有关部门批准后在南京市鼓楼区东妙峰庵附近新建了3栋住宅。最初每栋住宅只有四层，分为三个单元：东边单元、中间单元和西边单元。户室号以幢、单元和层的优先级进行编号，每栋有36户。图中楼盘表所在的这栋为第三栋，编号从73开始编号（一层的101室）。1989年，这栋房子在领取建设工程执照后加盖了两层，命名规则在之前逻辑的基础上命名为加1室、加2室、加3室等。
而这张楼盘表中所呈现的与上述户室号编排逻辑有所差异的户室，也在浩浩汤汤的中国房产改革历史下、不动产登记和交易的洪流中，被推动着向前迈进，结合时政和业务动态得更新了相关信息。
图：户室信息变更记录
在时间大尺度下，政策在变，信息在变。此时，你是否好奇，在内部信息如此差异的情况下，这张楼盘表是如何构建起来的？
统一时空框架
楼盘表最早兴起于房企。2015年9月，住房和城乡建设部办公厅印发了《房屋交易与产权管理工作导则》，在其中列举房屋交易与产权管理内容时，正式提出房屋交易与产权管理中楼盘表概念，并把楼盘表管理列为重要项。从此，楼盘表被赋予了新的作用，成为开展房屋交易与产权管理工作的核心工具和数据资源。但是有个问题，没有标准去定义楼盘表该如何构建？于是，围绕着相同的楼幢，不同的部门、应用、专题等构建了各种各样的楼盘表。时间久了，信息差异化发展，无法协同同步。
图：各式各样的楼盘表
自然资源部于2019年开展了全国国土空间规划一张图建设工作。简单来说这里的一张图就是一张地图，一张由地图投影变化得到的平面底图。这里需要思考借鉴的是，地球这个实体是相对稳定的，基于这个相对稳定的三维实体经过变换得到的这张图也就是稳定的，这张图就可以称之为系统内部开展工作的统一时空框架。大家在这个框架下独自开展工作，后续各自的成果可以有效共享。
那么，房子这个三维实体一旦建成，则也是相对稳定的。有了这个稳定的基础，能否得到属于房屋建筑的统一时空框架呢？这里，我们对楼盘表进行了重新定义：基于建筑三维产权空间实体，通过一定规则和空间变换等方式，得到具有拓扑关系的产权二维分布视图。表格的结构只跟三维实体的结构相关，不会因为实体业务数据的缺失、质量参差不齐而结构变动；可以作为房产专题下的统一时空框架，有效进行信息的共享和聚合。同时，不同的户实体在三维空间中的空间关系可以由二维楼盘表部分体现。
图：房屋二三维楼盘表
那么这里提到的建筑三维产权实体该如何高效地获取呢？南京市住房保障和房产局在房屋统一楼盘表项目建设过程中，采用Holo Architecture建筑产权三维建模平台，结合BIM技术，快速完成南京全域30万幢建筑三维模型的生产任务。同时，该建模流程已经正式纳入房产测绘流程，一方面完成产权BIM数据的采集和入库，发布为二维楼盘表支撑应用；另一方面通过三维产权模型直观地核验相关数据。
图：建筑产权BIM建模
房屋统一编码
这里的编码是对实体的编码，不是对数据的编码。在计算机层面，人、房子、地块等都可以抽象成为一条数据，通过Guid标记存储在数据库中，但这个Guid对于实体对象对外扩展应用而言是没有意义的，需要有一个实体编码来支撑。就像人的身份证编码一样，可以跨越时间（生老病死）和空间（衣食住行），满足多部门信息共享和聚合。
6、70年代以前，房产管理重地轻房，之后管理倾向于重房轻地，因此编码方案由丘号过渡到丘权号。这套编码框架已经沿用了近百年，时至今日，已经无法满足房产管理的精细化业务需要。例如，房产测绘有预测和实测两个业务周期，而丘权号编码方案是对实体的编码，本身没有预测或者实测的区分。部分应用平台作为使用方，通过编码获取得到预测数据，但误以为是实测数据发布出去，对外则会造成一些公共影响。另外，BIM时代下，管理者所聚焦的建筑房屋管理粒度从分层分户已然发展到分户分间分构件，传统的编码方案亟待更新。
图：房屋统一编码方案
南京房屋统一楼盘表项目建设过程中，多方呕心沥血，共同研制了江苏省地方标准《城市房屋三维基础数据模型及编码标准》（DB32／T 5168-2025），具体设计思想和内容可参照标准，此处不再赘述。这里需要补充的是，这是一套行之有效、且可落地执行的编码方案。至于是否有效，大家可以从两点去评估：（1）同一实体经过多次数据治理时，编码能否保持稳定；（2）不同的实体在分时、分阶段治理时，后者是否影响前者的编码。
图：户产权实体重复
关于有效性，倒是在实际应用过程中反向做了验证。应用平台在通过编码调用实体对象的时候，得到了两条重复的数据。当时笔者第一时间也是非常紧张，但通过排查发现，原始数据（户产权实体）在采集建模过程中重复建了两次，即实体重复导致的编码一致。
全生命周期
编者需要强调的是，编码不是一成不变的，因为实体是在发生变化的。实体本身存在物理周期，比如房子从施工建成到竣工灭失，对于编码的影响读者可能无法感同身受，这就要强调实体的业务周期了。对于买房子，曾经在一定时期内存在这样一种情况：产权人买了多套房，但只办理了一本证（房产证），即多套产权作为一个载体承载一个编码和业务信息；但在后续产生交易的过程中，产权人交易部分房产，产权实体则需要被拆分从而支撑业务需要。这种情况下，需要新的编码来支撑业务，编码肯定是要发生变化的。
如果业务相对简单，重新编码大家协同一下信息就可以了。但是，房屋建筑相对来说是一个跨越时间尺度较大（纵向）的地理实体，同时需要支撑的业务部门（横向）甚广，从设计、建成，再到运维和灭失，多部门很难做到协同一致，很多信息没有业务的驱动就静态存储在那，比如文章开头的楼盘表中部分户室在没有办理交易的情况下，户室号的信息至今都是滞后的；再比如当产权拆分编码发生了变化，有些应用平台所存储的编码还是滞后的。当产权人在A部门拿到了新的编码，然后去B、C、D其他部门办理业务的时候，结果却是查无此房。接下来房子还要扩展更多的业务，比如房屋体检、保险等……可想困难重重。
试想，编码只是一个纽带，我们通过编码是想要找到编码背后的实体对象。如果围绕着实体，整合实体（物理）周期、业务周期、数据周期，构建一套围绕着建筑实体（并非建筑工程项目）的全生命周期管理体系，管理实体的发展血缘——通过旧编码能够沿着血缘查到最新的编码，找到对应的实体对象；也能够围绕着实体找到历史多版本发展脉络，则会极大的提高业务效率。全生命周期管理体系需要做的有很多，比如结合具体业务定向异常驱动、建立消息通讯、构建多粒度数据中台等。房屋统一楼盘表有幸完成了这项工作。
图：房屋全生命周期管理
故事还在继续
我们通常关注的位置是物体的物理位置，有没有可能你还关注物体的其他位置：什么？还有其他的位置？有的，比如：语义位置。比如你家的电表和邻居家的电表一起放置在地下室的电表箱中，这是电表的物理位置。401电表、402电表、403电表……电表背后所代表的房子实际位置可能是我们更关注的，401这套房子一个月或者一年用了多少电量等。401就是电表的语义位置。
图：全域治理
你有想到什么吗？南京房屋统一楼盘完成了南京全域30万幢房屋建筑产权BIM数据的治理工作，它不仅仅是一张张楼盘表，至于它是BIM、CIM还是TIM，这个交给各位专家、同行来评判。结合上边的例子，这里想补充的是：如果电力或者其他专题物联网数据和这份数字城市底座能够产生化学反应（下图），电表则从冰冷的地下室迁移到它所代表的空间实际位置（房屋产权实体），以点带面——哪家异常用电、哪家长时间没有用电、区域（商业、住宅）用电情况，这能否成为智慧城市的敲门砖呢？
最后，在这里致敬一位已经退休且从事房产测绘工作四十余年的吴老先生，尘封的历史能够跃然纸上，房子的故事得以延续；也要感谢每一位参与楼盘表建设的同志们，轻舟已过万重山。
点击蓝字 关注我们
