GeoBIM solutions for the Digital Building Permit process

All documents are licensed as a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License
(Attribution-Non-Commercial-ShareAlike 4.0). Further information can be found at

creativecommons

The documents reflect the current best practice and do not claim to be complete. They should not to be understood in the sense of a generally valid recommendation or guideline from a legal point of view. The documents are intended to support appointing and appointed parties in the application of the BIM method. The documents must be adapted to the specific project requirements in each case. The examples listed do not claim to be complete. Its information is based on findings from practical experience and is accordingly to be understood as best practice and not universally applicable. Since we are in a phase in which definitions are only emerging, the publisher cannot guarantee the correctness of individual contents.

This use case formalizes the end-to-end Digital Building Permit (DBP) process established in the scope of the CHEK project to enable the automation of compliance checks and enhance the building approval experience. It describes BIM and GIS integration workflows based on open standards such as IFC, CityGML/CityJSON, IDS, and LoIN and ensures that every data exchange and validation step is transparent, repeatable, and interoperable.
Each process step is linked to explicit Exchange Requirements (ERs) and Level of Information Need (LoIN) definitions. This approach guarantees that municipalities, designers, and software vendors share the same understanding of the information required for automation and legal traceability.

BIM plays a central role as it is the format (IFC) in which applicants are required to submit their building proposals to competent authorities (municipalities). The process lifecycle involves:

1. Pre-submission (Applicant) – City data collection (CityGML/CityJSON), zoning API integration, design authoring in IFC with LoIN compliance, and pre-check using the same rule engine as municipalities.
2. Digital Building Permit (Municipality) – Official submission of validated IFC via the CHEK platform, automatic schema and data validation (IDS + CityJSON), visual review, automated rule-checking (Pass/Fail/Discussable), and digital approval.
3. Post-permit & As-built Integration – As-built model updates, BIM2GEO conversion to CityGML, and integration into the municipal 3D city model for long-term digital twin management.

Each phase aligns with geometric, alphanumeric, and documentary LoIN requirements and operational validation through shared rule engines (VCMap, Verifi3D, CYPEURBAN).

As an end-result to the standardised DBP process, the following output are produced:

• Faster administrative approval of a building’s permit
• As-built IFC model of the building
• As-built equivalent GIS model of the building
• Enriched / up-to-date city model for the municipalities 

• BIM and Geo data conforming to IFC 4.3 ADD2, CityGML/CityJSON v3 profiles
• Zoning, cadastral, and terrain data via OGC APIs
• IDS and LoIN templates derived from CHEK’s Ascoli Piceno pilot

• Enable automatic, transparent regulatory checking across jurisdictions
• Increase trust through standardized, machine-readable validation
• Reduce manual review time for municipalities and applicants
• Foster cross-platform interoperability using open standards

The use case does not address legal text interpretation or national-specific approval procedures; it focuses on the digital and technical processes enabling automation.

Implementation requires an DBP environment based on OpenAPI and OGCAPIs shared rule engines, and alignment with standards from bSI, OGC, ISO 7817-1, ISO 19650-4, and ISO 23386

DBP – Digital Building Permit 

IFC – Industry Foundation Classes 

IDS – Information Delivery Specification 

LOIN – Level of Information Need 

UCM – Use Case Management 

OGC – Open Geospatial Consortium 

bSI – buildingSMART International

To ensure interoperability and consistency across the Digital Building Permit (DBP) lifecycle, each process step within the process map is linked to a clearly defined LoIN. This includes geometric, alphanumeric, and documentary requirements, complemented by operational considerations (how and when the information is used) and check options (validation mechanisms).

The LoIN ensures that all parties—designers, software tools, and municipal authorities—work with the same understanding of what information must be present at each stage of the process.

The DBP process lifecycle is divided into three main phases:

1. Pre-submission (Applicant) – design preparation, data integration, and pre-checks.
2. Digital Building Permit (Municipality) – official submission, validation, and approval.
3. Post-permit and As-built Integration (Municipality) – model updates and city model integration.

Each phase is linked to the Exchange Requirements (ERs) defined in the CHEK UCM.

Geometric information

Geometric information defines the level of spatial detail and the geometric accuracy required at each stage of the process.

• ER-1 – City Data Extraction: LoD0–LoD2.2 geometries, including cadastral parcels, terrain (DEM), and surrounding buildings. Terrain must reference an EPSG CRS; neighbouring buildings are modeled as LoD2 solids.
• ER-2 – GIS-to-BIM Conversion: LoD1 context extrusions mapped from CityJSON to IFC. Geometry conversion maintains zoning boundaries, parcel limits, and site extents.
• ER-3 – BIM Export (IFC + IDS): Building outer shell, roof intersection, and façades modeled at LoD2–LoD3; roof lines align with zoning height thresholds.
• ER-4 – Schema & IDS Validation: IFC solids validated against EXPRESS schema; geometrical properties such as height, area, and distance encoded in Property Sets.
• ER-5 – Georeferencing Validation: Origin, rotation, and scale defined through IfcSite and IfcMapConversion; verified against national CRS (EPSG).
• ER-6 – Automated Rule-Check: 3D geometry used to calculate height-to-terrain distance, setbacks, and façade window coverage.
• ER-9 – City Data Validation: CityJSON/CityGML validated for semantic and geometric completeness of parcels, buildings, and zoning volumes.

Alphanumeric data ensures that all entities are semantically complete and traceable through attributes, classifications, and codes.

• ER-1 – City Data Extraction: Attributes include ParcelID, ZoningRef, and land-use code.
• ER-2 – GIS-to-BIM Conversion: Mapped attributes (CityJSON → IFC) stored as IfcPropertySingleValue; zoning and parcel IDs retained in mapping tables (XLS/CSV).
• ER-3 – BIM Export (IFC + IDS): Core properties include IsExternal, CHEK_common.Height, and IfcBuildingStorey.Area.
• ER-4 – Schema & IDS Validation: Attributes populated in required property sets (GFA, height, distances).
• ER-5 – Georeferencing Validation: EPSG codes, vertical datums, and unit consistency checked.
• ER-6 – Automated Rule-Check: Functional and regulatory attributes, e.g., +hasWindows, zoning category, and building use type.
• ER-9 – City Data Validation: Land-use, legal height, and building function attributes validated against city profile.

Documentation links all geometric and alphanumeric data to legal and procedural sources, ensuring traceability and auditability.

• ER-1 – City Data Extraction: Metadata of source datasets (e.g., cadastral origin, licensing).
• ER-2 – GIS-to-BIM Conversion: Conversion log and mapping table (CityJSON–IFC attributes).
• ER-3 – BIM Export (IFC + IDS): Legal references and applied IDS templates.
• ER-4 – Schema & IDS Validation: Validation report logs and compliance certificates (PDF).
• ER-5 – Georeferencing Validation: Survey coordinate reference, EPSG CRS documentation.
• ER-6 – Automated Rule-Check: Regulation thresholds and reference parameters (JSON or CSV).
• ER-7 – Validation Report: Consolidated rule-check reports (JSON/XML + human-readable PDF).
• ER-8 – IFC Signing: Digital signature metadata, timestamps, and XAdES/eIDAS documentation.
• ER-9 – City Data Validation: City profile specifications and validation reports.

Each LoIN element must be operationally verifiable through the same validation engines used by both applicants and municipalities:

• Schema/IDS checks: EXPRESS and IDS validation for completeness and correctness.
• Semantic/Geometric checks: SHACL and val3dity applied to CityJSON/CityGML.
• Rule checks: Automated evaluation of height, distance, and buildability rules via VCMap, Verifi3D, and CYPEURBAN.
• Digital signing and traceability: IFC signing to ensure authenticity and integrity of submitted models.