Pset_BuildingStoreyCommon new property IsActualBuildingStorey

[tomi-p]

This property would emphasise whether or not the building storey is a standard floor which is calculated to, for example, gross area. If set to FALSE, then the building storey is a foundation, roof or any other level, which is necessary for design or collaboration purposes, but is not considered an actual floor in the actual building. Alternatively name of the property can be IsActualFloor (TRUE/FALSE).

[Moult]

I don't think this is a good idea. It's basically a property which if set to False implies that IfcBuildingStorey is not the correct class to use. It sounds suspiciously like a translation of Revit's ability to mark whether a floor is actually a floor.

If you want to annotate other levels (top of parapet, roof ridge, etc), use IfcAnnotation. You shouldn't be using IfcBuildingStorey in the first place.

[tomi-p]

This is necessary for building permits (IFC4 will become mandatory for all building permits in Finland). In Revit, it is actually quite easy to exclude levels from IFC export that are not relevant. But the design also talks about foundation and roof levels, which are not actual building floors. So levels that are not actual floors are a necessity in the model. At the same time, in the permitting process, the goal is to machine read the number of floors, and only include actual floors.

[Moult]

Sure, so if its not a floor, don't use IfcBuildingStorey.

Use something else, like IfcAnnotation with an object type.

[tomi-p]

Unfortunately, it is not possible to save floors as IfcAnnotation in e.g. Revit. But we can come back to this later when we make a proposal for new Psets in the Regulatory Information Requirements project (a bSI Regulatory Room project).

[AlexBrad1eyCT]

Firstly the below quote i believe is not correct, you can force revit to map its objects to quite extreme variations.

Unfortunately, it is not possible to save floors as IfcAnnotation in e.g. Revit. But we can come back to this later when we make a proposal for new Psets in the Regulatory Information Requirements project (a bSI Regulatory Room project).

For example you "can" export a revit level as an IfcAnnotation by using the override parameters built in to Revit's IFC export., but IMO this is not the correct mapping. revit already has a boolean parameter for saying this is not a building storey.

In the current schema, and the orginal intended design since the start of IFC4.3 would be to use IfcFacilityPartCommon with attribute UsageType set to IfcFacilityUsageEnum.VERTICAL, you can set the type of level (top of parapet, roof ridge, etc), using the standard user-defined typing method.

this came about because infarstructure required a way to encode vertical level datums in models, the predefined types illistrate this, and fits nicely with the buildings use case of non-floor level markings (top of parapet, roof ridge, etc), that provide positional context.

Side note (Variations): per the current definitions of IfcAnnotation:

An annotation is an information element within the geometric (and spatial) context of a project, that adds a note or meaning to the objects which constitutes the project model. Annotations include additional points, curves, text, dimensioning, hatching and other forms of graphical notes. It also includes virtual or symbolic representations of additional model components, not representing products or spatial structures, such as event elements, survey points, contour lines or similar.

these levels should only be IfcAnnotations when they do not provide positional context (in revit speak; other objects do not use them for relative positioning), IMO anything that provides positional context should always be a subtype of IfcSpatialElement. but i am open to discussion.

[tomi-p]

If we're just looking at Revit, it's possible to export levels as you want, but it affects all levels, and that's not the point. However, Revit is just one piece of software. The building permit requirements must be such that any software that is IFC4 certified can produce the required data. The data should also be exportable from all software in the same way. In addition, all architects (who are not IFC certified) must have a reasonable means to do so. That is why we need simplicity.

There are about 11,000 building permits in Finland every year, and from the beginning of 2025 about 2/3 of them will have to be applied for using IFC4. And this is just Finland. In Estonia, IFC is already used in the permit process, and other countries such as the UK, Japan, Singapore, Portugal, Italy and the Netherlands are preparing for this.

I would have needed this feature on building storeys now, because the ministry asked for it in connection with the national information system on the built environment, which is currently being developed.

However, we can discuss this later, once we get a list of new regulatory properties agreed in the RIR project. At the moment it looks like there will be over 1000, but we are working on it to clean up the list.

[AlexBrad1eyCT]

To conclude software should map:

Any level that IS a building storey maps to IfcBuildingStorey

Any level that IS NOT a building storey maps to a subtype of IfcFaciltyPart which ever is most relevent with UsageType set to IfcFacilityUsageEnum.VERTICAL

[aothms]

I'm supportive of this idea. For drawing/coordination purposes there can indeed exist levels that will not be recognized as levels in the day to day operation of a building. Like foundation or roof. They do have an elevation and potentially aggregate a set of spaces, so I'd still say IfcBuildingStorey is still a better semantic fit then IfcFacilityPartCommon. It's also more compatible with earlier versions of IFC. There is currently no guidance on property sets to have a IfcFacilityPartCommon.VERTICAL store things like elevation.

I would be tempted to think though that something like this can also be determined by the existence of spaces on this level or certain local classification of space types, because in my naive understanding that is ultimately what governs this. To move this discussion further, can you @tomi-p provide a couple of real-life examples of "non-storey storeys" so that we can jointly assess the best way to represent them?

[tomi-p]

I will collect examples from RIR members and get back to you as soon as possible.

[AlexBrad1eyCT]

So a few things:

I'd still say IfcBuildingStorey is still a better semantic fit then IfcFacilityPartCommon

but the example and context this is addressing is levels that are not building storeys. As @Moult said if it is not a building storey then it shouldnt be an IfcBuildingStorey. it could be any subtype of IfcFacilityPart not just IfcFacilityPartCommon.

It's also more compatible with earlier versions of IFC.

compatability is irrelevent. it was done that way before because there were no better semantic options, the UsageType attributes, purpose is to give directional context to spatial subdivisions. if you are not going to use the new features of the schema why do we need to extend it... backwards compatability is for technical compatability not semantics.

I would be tempted to think though that something like this can also be determined by the existence of spaces on this level or certain local classification of space types

@aothms I actually agree with you on this one we have lots of short cut properties that transfer the same information to a different place within the data model (elevation properties for example, which should be quantities as they are calculated from geometry, but thats one for another day). so in a perfect world these things should be derived from the context of the entity.

[Moult]

Yeah just to clarify I'm in support of being able to semantically include the concept of a significant "Level" (e.g. top of parapet), however I'm questioning whether it should be an IfcBuildingStorey. In English, if somebody said which storey / floor (synonymous?) is object X on? I wouldn't imagine anybody to interpret "Top of parapet" as a storey / floor. It starts to blur the semantics of "Spatial container" too. "Is object X contained in the top of parapet? Huh?"

[Moult]

IfcVirtualElement may be a contender for this: https://ifc43-docs.standards.buildingsmart.org/IFC/RELEASE/IFC4x3/HTML/lexical/IfcVirtualElement.htm

A virtual element is a special element used to provide imaginary, placeholder, or provisional areas, volumes, and boundaries. Virtual elements are usually not displayed and do not have quantities, associated materials, and other measures.

[aothms]

I may be misreading this issue, but I have the suspicion @tomi-p is looking for a spatial structure element in the spatial hierarchy of the project, not an annotation or virtual element.

[TLiebich]

In my understanding the topic is about how to map levels (as in Revit, but similar also in Allplan and maybe others) which are horizontal planes mainly used as modeling aids (element z-Positions and heights relative to levels) to the equivalent IFC structure. In Revit there is an option to declare a level to correspond to a story.

Those levels map to IfcBuildingStory, all others are not exported (no direct equivalence to such modeling aids in IFC).

The discussion seem to be twofold.

1) original questions by Tomi: for those stories, that are mapped to IfcBuildingStory, is there a way to distinguish between storeys that count as inhabitable storeys for building permits, e.g. to exclude a storey representing a roof area

2) what to do with all other levels, that are currently ignored in IFC

to 1) a property for a pset should be the solution to 2) neither annotation nor virtual element sounds like a close semantic match. To me it is rather a particular position element - along with grid and alignment - that could be used along with IfcRelPositions

[tomi-p]

Levels that exist only for modelling purposes are not a problem, as they can be ignored in IFC export (or converted to annotations if necessary). However, on a construction site, one is interested not only in the "real" building layers but also in the foundations, roofs, terraces, and other levels typically handled by authoring tools in the same manner as building stories. End users, as well as the building authorities, are mainly interested in the habitable building storeys.

Whatever the solution, please note that it is needed now, not in five years, when the next version of IFC is available and supported by software.

[aothms]

For 1) I don't think the building storey is necessarily the appropriate level. It seems to me this is a property of IfcSpace and can be inferred on a storey level by a permit checking application when all spaces on a storey are of this nature.

For 2) hence my earlier question do these levels contain or position elements? If they are modelling aids I would assume that their positioning is relative to them.