IFC (openBIM) exchange

Read and write ISO 16739 IFC files: import a coordination model to see it beside your design, import an alignment natively so it becomes real geometry you can edit, and export your design as IFC 4.3 for the rest of the project team.

What the versions mean for you

Importing

IFC ▸ Import IFC Model reads a file in three passes, and tells you in the message log exactly what each one produced:

• Geometry. Every product with a shape becomes a display mesh. Each object keeps its IFC GlobalId, its class (IfcWall, IfcSlab …) and its property sets — click one in 3D and the Properties dock shows them.
• Alignments (4.3 only). Each alignment becomes a real alignment node: line, arc, clothoid, the Bloss / cosine / sine / Helmert transition family and the cubic parabola all map to native segments; the vertical layout becomes a profile with parabolic and circular curves; a cant layout becomes a stored cant profile.
• Structure. The spatial tree (site, building, road, railway, bridge and their parts) and the layer entities (course, pavement) appear in the Object Browser with their properties.
• Records. A product with no body — an axis, a marker line, a point device — cannot be drawn, but it is not dropped: it keeps its GlobalId, class and property sets as a row on the model, and the log says how many arrived that way. The modules then read back what they know: rail joints exported by yucad3d become the joint schedule of the track of the same name in your document, placed on your copy of that track (no track of that name: the records stay, and the log says so). Fouling points deliberately stay records — a fouling point is derived from a turnout, and a marker is not a reason to invent one.

Editing IFC as IFC

An imported model keeps a live link to its file. Property values shown for a picked object are editable: changing one writes into the IFC file in memory, and IFC ▸ Save IFC Edits writes it back to disk.

• Undo works normally — one undo restores both the value you see and the value in the file.
• Types are preserved: a property the schema defines as a boolean stays a boolean. If what you type cannot be that type, the edit is refused and nothing changes.
• Nothing touches the file on disk until you save.

Merging two files

IFC ▸ Merge IFC Files asks for a base file, a file to merge in, and where to write the result. Objects carry a GlobalId, and two files can legitimately contain the same one; the merge never resolves that silently — duplicates are given a fresh GlobalId (the copy IS a new object) and the counts are reported.

Exporting

IFC ▸ Export Alignments (IFC 4.3) writes the document as native IFC 4.3: alignments with their horizontal, vertical and cant layouts, the spatial structure, and imported models as tessellated products that keep their original GlobalId and class.

Exporting to an older version is refused with a loss report listing exactly what that version cannot carry, rather than quietly writing a file that has lost your alignments.

Stationing. IFC 4.3 measures the vertical and cant layouts from the start of the horizontal, not in the project’s kilometrage. An alignment that starts anywhere but 0+000 therefore carries its start station as an IfcReferent (type STATION) with Pset_Stationing.Station, and every layout is written relative to it; the importer reads it back, so a track starting at 12+000 comes back at 12+000 with its profile and cant where they were. Its domain comes back too: an imported alignment is a rail or road alignment according to the facility it positions (IfcRailway, IfcRoad); only a file that states none falls back to “has a cant layout, so it is a track”.

What rail objects become

A rail alignment is an IfcAlignment with its horizontal, vertical and cant layouts — and, since #367, two IfcRail products as well: the left and right running rails at ±gauge/2, at the level the profile gives, the left rail raised and the right lowered by half the cant, each with a solid rail-section body along its whole length. The gauge is the cant profile’s rail-head distance when the file states one and 1.435 m otherwise, and the product’s property set says which (GaugeBasis). A polyline track (the older Rail Track object) gets the same two rails and the same body, but it carries no profile, so its rails sit at z = 0 and its property set says so (LevelBasis) rather than pretending a level.

Only tracks get rails: a designed rail alignment, or a parallel track laid as an Offset of one. The lines Rail Lines and Platform Edge lay beside a track are companion lines (kind Misc): they export as alignments, not as another pair of rails, and the rail design checks do not repeat their track’s issues under their names.

Turnouts and cant have always crossed. So do the two rail objects that are physical things which get built and staked:

• Rail joints — one discrete accessory per joint, its axis along the rail, sitting at rail level where the track carries a profile, and a solid body a receiver sees in 3D: a fishplate’s length of rail, rail-head wide, rail high. The kind appears in the name, in ObjectType and as a property, because a weld, a fishplated joint, an insulated joint (a signalling boundary) and an expansion device (a structural one) are read by different people looking in different places.
• Fouling points — a marker per route, both of the pair, each carrying the spacing it was found at and the rule that decided it. A staked point whose basis is not written down cannot be checked by whoever finds it later. Where the rail level is known the marker also gets a post as its body; a marker whose turnout is missing has no level, and it keeps its axis alone rather than stand a post on z = 0.

Every product with a body also carries BaseQuantities: its GrossVolume, computed exactly from the closed body, and the Length of its axis — so a take-off reads the numbers instead of re-measuring a tessellation. A body wound inside-out would sum negative; that is reported in the loss list rather than written as a number that looks right. The set is named BaseQuantities like the corridor courses’; buildingSMART’s per-class Qto_* names are not in the schema itself and are not guessed.

The body dimensions — rail height and head width, fishplate length, marker height — are the railway’s data and come from the loaded standard when it states them. When it does not, a stated default is used and the product’s property set says so in BodyBasis, so the number never travels without its source.

The clearance envelope and the turnout level plan are deliberately not exported, and their loss lines say so. They are analysis, not products: IFC has no honest class for a swept envelope or a level table, and sending them as proxies would put noise in the model and imply a status they do not have. Re-run them on the receiving side, where the sources are.

The predefined types have been checked against the IFC 4.3 schema rather than assumed. An expansion device is written as EXPANSION_JOINT_DEVICE and a fouling point as MARKER, both of which the schema names. A weld, a fishplated joint and an insulated joint have no item of their own, so those three keep USERDEFINED with the kind spelled out in ObjectType — the schema’s own idiom for that case, and what it requires there. That is now a checked decision rather than an uncertain one: less specific than an enum item, never wrong, and only used where the schema genuinely offers nothing better.

Both classes are IFC 4.3 additions. Exporting to IFC4 or IFC2X3 writes them as proxies carrying the class in ObjectType, and says so in the loss report — the same treatment track itself gets there.

The property sets yucad3d publishes

Every property yucad3d writes lives in a YuPset_* set, and since #362 the file describes those sets itself: each family gets an IfcPropertySetTemplate naming its fields, the type each value is written in and the product classes it applies to, and every instance is bound to it. A receiving system reads the schema from the file rather than from this page. What the fields mean is here:

Templates are written by the IFC 4.3 export. An IFC4 file carries the same property sets without templates and the loss report says so; IFC2X3 has no such entity. bSI’s own Pset_* sets need no template from us, and a set carried through from an imported model is not ours to describe.

Validation

Exports are checked against the official buildingSMART Validation Service — STEP syntax, IFC schema and normative rules all pass. Two advisories remain by choice: we do not invent station referents, and we do not invent a coordinate reference system. Both are real data the file simply does not have; fabricating them would make the file look better and BE worse.

Practical notes