First of all this brings about the first discussion point. For all of the Bentley people this is not the CAD Level, we can investigate those along with the Autodesk Layers and the Revit categories, but this is related to the building Levels / Floors / Storeys / Storys. For the purpose of this article I will be using Floor, but wanted to be contensious with the headline ;)
So I was going to extend the dashboard for the toolbox app and one of the challenges we saw with the projects at Bentley was the contractors would invariably have their own floor naming convention as well as slightly different co-ordinate / elevation offsets.
I can show the challenges with the Hospital IFC project rather than having to show live project examples.
Generally we created a report that would show all of the floors grouped by name with the elevation A simple query should be acceptable
select userlabel, ifcelevation from IFCDynamic.ifcbuildingstorey group by userlabel
In our example project returns 19 records.
Adding the ifcelevation to the group by returns 23 records. Wait, so some files are using a slightly different elevations for their floors.
select userlabel, round(ifcelevation,4) from IFCDynamic.ifcbuildingstorey group by userlabel, round(ifcelevation,4)
Should fix it, but turns out Level 7 in this example model has a discrepancy of 3m
It looks like one of the contractors that has used Level 7 should have named it Level 7A

I guess the remaining question is, when should a contractor use floor names convenient to them ?, TOS is consistent in this case and is always 150mm below the main floor and Ceiling where used is nearly consistent at 2.75m above the main floor, but not always.
I was going to enhance the standard Floor quality card

with a fairly comprehensive query
WITH s AS (
SELECT
ECInstanceId,
ifcname,
ifcelevation,
LEAD(ifcelevation) OVER (ORDER BY ifcelevation) AS next_elev,
LAG(ifcelevation) OVER (ORDER BY ifcelevation) AS prev_elev
FROM IFCDynamic.ifcbuildingstorey
),
s_flags AS (
SELECT
ECInstanceId,
ifcname,
COALESCE(ifcname, '<<unnamed>>') AS label,
ifcelevation,
CASE
WHEN COALESCE(next_elev - ifcelevation, 99999) < 5
OR COALESCE(ifcelevation - prev_elev, 99999) < 5
THEN 1 ELSE 0
END AS smallGapFlag,
CASE
WHEN NOT REGEXP('LEVEL \d{1,2}', COALESCE(ifcname,'')) THEN 1 ELSE 0
END AS badNameFlag
FROM s
),
name_inconsistent AS (
SELECT
ifcname,
CASE
WHEN COUNT(DISTINCT ifcelevation) > 1 THEN 1 ELSE 0
END AS elevations_inconsistent
FROM IFCDynamic.ifcbuildingstorey
GROUP BY ifcname
)
SELECT
sf.label AS label,
COUNT(*) AS instanceCount,
SUM(sf.smallGapFlag) AS smallGapCount,
SUM(sf.badNameFlag) AS badNameCount,
SUM(CASE WHEN COALESCE(ni.elevations_inconsistent,0)=1 THEN 1 ELSE 0 END) AS inconsistentElevationCount
FROM s_flags sf
LEFT JOIN name_inconsistent ni ON sf.ifcname = ni.ifcname
GROUP BY sf.label
HAVING SUM(sf.smallGapFlag) > 0
OR SUM(sf.badNameFlag) > 0
OR MAX(COALESCE(ni.elevations_inconsistent,0)) = 1
ORDER BY label;
which does indeed show that everything is bad, so what would you do, stick with the simple floor naming convention and have static TOS floors or understand you could have non-standard floor depths ie the diference between the TOS and the floor elevation.
Ensure that there is a minimum ceiling height and where there is a defined ceiling height ensure it is the minimum height of 2.75m or refer to the building specification(s) for example the
NHS specification and associated standards does allow between 2.4 and 2.7, so the design would pass.
I have shown in previous articles we could have AI crawl over our design against the design specifications, but the recent trends tend to show this is not a scalable solution Uber AI burn and as such some simple validation checks, yes perhaps developed with AI may still be the medium term solution.
How do you check the floors and elevations are consistent on your projects, specially when using tools as OpenBuilding Designer?
Do you want a specific check for your project, why not make a request feedback or github