PDF Export of Requirements

Export the information requirements from the platform as PDF to use as attachment for your documents. The PDF export would at least include a table of requirements for each specification listing the required properties (incl. data type, property set, value lists etc.) and the assignments to information levels. The export could be filtered e.g. by discipline to create specific documents for different project partners.

Relationships between specifications (part of instead of inheritance)

Not always is the inheritance useful. There are two cases of how you would want to deactivate the inheritance: Complete detachment of the specification from the parent specification: None of the properties should be inherited as the specification describes a complete different element, that is just subordinated to the parent specification to show the thematic affiliation. — other issue

Document Requirements

Should work similar to specification properties Specify which elements / specifications need to have specific documents linked Specify in which information levels / phases of the project the documents are needed, equal to the checkbox loin management of the properties Central list of required documents Documents are inherited, just like properties Each document can have the following metadata attached Name Description (optional) File Format (optional) Tags according to tag groups

Allplan Integration

The integration for Allplan will support the attribution process within Allplan similar to the plugin for Revit. It will help with the managing of the properties, filling in the relevant values and checking if anything was missed.

Archicad Integration

The integration for Archicad will support the attribution process within Archicad similar to the plugin for Revit. It will help with the managing of the properties, filling in the relevant values and checking if anything was missed.

IFC Attribute Support

Define requirements for the IFC attributes like “Name” and “Description”, that don’t live in property sets but are built into the IFC schema itself. Next to defining the requirements, it will be possible to check these requirements in the IFC studio and to edit the attributes with the Revit plugin (limited to the attributes that can be overwritten in Revit).

Scripting / automations for attribution

Allow user to create own scripts to automate the attribution. This could come in form of… Option 1: a node editor similar to Dynamo for Revit Option 2: a code editor similar to the scripts in Desite Let us know which option you prefer!

Filter Options for Excel Export of Requirements

Filter options for: Domains Tags Information Levels -> E.g. get one Excel file for every domain so that everyone only receives the requirements that apply to them.

Improved Property Values

Currently the property values are simple lists of values, but often additional information like a description or tags on the values, would help the user in choosing the right value. This feature will add: A way to edit existing property values (this will also update all references to the value everywhere) Support for tags on property values (which will also enable you to filter out values in the plugin / IDS export) An optional description for each property value, to give the user additional information during the attribution.

Multi-Property Rules

Currently it's possible to define restrictions for single properties globally or inside specifications. More complex scenarios often require us to check multiple property values against each other. One example would be a check that ensures that DateA comes after DateB.

Property Rule: Unique Values

Add an additional rule for properties which enforce that a value is unique across all elements in the validation set. This won't be supported by IDS, but would work inside the validation in our plugins and inside the IFC-Studio.

Cross-Catalog Property Mappings

When two or more parties are working together on LastBIM and have their own catalogs, you might want to map them on each other. E.g. the BIM management provides a catalog with the properties that are required for this project. The planners have their own standard. The planners want to map the the properties required of the BIM management on their own properties, to work e.g. in Revit as usual and only add properties that are not covered by their own catalog. While you can already define how a required property is handled in Revit, this feature would allow you to map the properties of two catalogs at once, by selecting the corresponding property from the other catalog.

Plugin Data-Sync

Import, export, save and synchronize data from and into your models via the plugins (and IFC-Studio). Workflows covered by this feature: Change data in an IFC-Model (e.g. Desite / IFC-Studio) and synchronize the changes back into your native model (for example Revit). Export data (on its own or with validation results), hand it off to a third party and re-import the data after it has been updated into your model. Bulk edit data in your model via tables. Possible adjacent future workflows: Request data-changes from third-parties via a web user interface. Create a selection in your model and request-data for a all (or a subset) of its properties. Share a link with a third-party, which can then fill out the requested data in a view similar to our plugin. If the model is in IFC and uploaded, it'd be possible to highlight the elements

Export validation results as Excel

Exporting the validation results as Excel will give you a comprehensive tabular overview of the status of the attribution in the model. The Excel format allows you to bring the data in any form that you need, e.g. to create diagrams or to analyse it with Power BI.

Export validation results as BCF

Microsoft Login (EntraID)

Log into LastBIM without any additional credentials and use your already existing Microsoft Account.

Microsoft Login (EntraID)

Log into LastBIM without any additional credentials and use your already existing Microsoft Account.

Ensure compatibility of IFC classes and IFC properties in specifications

Currently, users can add every IFC standard property to every specification regardless of the IFC entity of the specification, meaning you could add the property "ExtendToStructure" (PsetWallCommon) to an IfcBoiler which would not be schema conform. Option 1: When adding a property to a specification, filter the IFC catalog for properties that match the IFC entity of the specification - if the specification is mapped on an IFC entity Option 2: Show a warning in the property table of the specification, when the property that is mapped on an IFC schema property does not match the IFC classification of the specification. This would help to use the IFC standard correctly in your catalog and avoid assignments that are not intended by the schema.

Import Properties from the DIN BIM Cloud

The DIN BIM Cloud is a comprehensive database for properties based on STLB-Bau and the DIN SPEC 91400. By establishing a connection between LastBIM and the DIN BIM Cloud, you can seamlessly import properties directly into your own catalogs and adopt properties from an already existing standard. This feature is particularly useful for users who are in the process of defining their own catalog and want to follow existing standards. Additionally, it would help to increase the adoption of the DIN BIM Cloud, potentially leading to more uniform attribution practices within the industry.

Deactivate Inheritance of Properties

Not always is the inheritance useful. There are two cases of how you would want to deactivate the inheritance: Complete detachment of the specification from the parent specification: None of the properties should be inherited as the specification describes a complete different element, that is just subordinated to the parent specification to show the thematic affiliation. Detachment of single inherited properties: Only some of the inherited properties should be removed while the inheritance of other properties remains unaffected. This way e.g. general properties that are places on an higher hierarchy level can be removed from single specifications where they are not useful without having to renounce the use of inheritance.