IfcSite RefElevation vs. IfcLocalPlacement Z value in IFC2x3

Developers
,
#1

Hello all,
I recently solved a Revit export mystery, and would like to get other’s input here. Before IFC2x3 CV2.0 implementation, we used to place the Z offset of the IFCSITE in both the RefElevation attribute and the Z value of the local placement. IFC2x3 made this illegal, so we removed it from the local placement, and immediately got a bunch of reports of sites showing up in the wrong place in other software. So we created a flag for “backward compatibility” to create broken IFC2x3 files that had both again, and that made the problem go away.

I kept hearing of people still using the value, though, and found out that some software ignores the RefElevation attribute and only looks at the local placement. So, the question for the implementers: do you use the RefElevation attribute, the Z value of the local placement, neither, or both? It seems like, for importers, we should settle on one. I know IFC4 solves this issue, but IFC2x3 will still be here for some time. My view is that the RefElevation attrbute is the right place, since that contains the most metadata, but would like to know other’s opinions.

#2

My two cents:

If you want to record a GIS coordinate, i.e. a height that is part of a height datum, then you should record it in RefElevation, as it is the same place where you put other GIS coordinates in 2X3 (RefLatitude, RelLongitude).

If you want to record the offset as an arbitrary project height, in the same way that you choose an arbitrary project origin, then it should be recorded in the Z axis.

Therefore, just as I would expect to see (0, 0) at some convenient project-specific origin, and then I would see a RefLatitude and RefLongitude which tells me the actual GIS coordinates (in 2X3, of course), I would expect the Z coordinate to be treated equally.

Hope it made sense.

#3

Dear @angel.velez I think Autodesk has enough community (someday I was part of this community too) and experts to solve these kinds of issues very sooner

It’s odd to us when see Autodesk finds these kinds of issues and their solutions too late

I don’t know this is the Autodesk problem or bSI problem

#4

Hi @ReD_CoDE, the issue is that this isn’t an Autodesk problem. Our default export is correct - it exports the site elevation in the RefElevation parameter, which is correct by IFC2x3 CV2.0 standards. The issue is that other products were ignoring this parameter, and as such we made a toggle to allow these products to continue working. However, that was several years ago, and we expected this to already be obsolete, but it wasn’t. So I did some investigating, by talking to our competitors, to determine the problem, and then decided to see what was the solution to this issue moving forward. Instead of having an Autodesk-dictated solution (“we will remove the incorrect work-around, and you must read in the correct RefElevation value”), we decided to ask the other implementers what they wanted, so that we would go with the consensus solution. Hopefully that explains why I came to this forum with this question.

#5

@angel.velez This sounds good and valuable

I think the issue is that Autodesk mainly has focused to implement IFC2x3 when other competitors day to day have improved their IFC2x3 solutions based on the findings in IFC4 and later

@jwouellette I think bSI needs to implement a way that let companies not only implement previous versions (Supported Tag), but also implement a part of the latest version in their solutions (Planned Tag) and when is needed and are ready give the latest version license too

I mean bSI shows not only Supported certificates, but also Planned certificates

Like this:

lis
lis.png1221×523 26.7 KB

I think this link will help: