DOCSEARCHbyAlgolia
Submit Docs

ifcJSON Specification

repository·main·Indexed 41 days ago

https://github.com/buildingsmart-community/ifcjson

A JSON-based representation of the Industry Foundation Classes (IFC) schema designed for easier data exchange and integration of Building Information Modeling (BIM) data. ifcJSON-4 prioritizes backwards compatibility, round-trip capability, and parallelism to the EXPRESS schema. The project includes a JSON Schema Draft-07 for validation and a Python-based converter, ifc2json.py, to transform IFC SPF files into ifcJSON format.

Tokens
7.6K
Snippets
11
Records
30
Agent score
51%

What's inside ifcJSON

  1. What is ifcJSON and its core objectives

    main

    ifcJSON is a specification designed to make IFC (Industry Foundation Classes) data available in JSON format. Its primary goals are to lower the barrier for developers who are unfamiliar with EXPRESS or STP instance files and to facilitate the exchange of linked, distributed, and rapidly changing building data, which is often difficult with traditional file-based IFC exchanges.

    The specification prioritizes:

    1. Backwards compatibility with the original IFC.
    2. Round-trip capability.
    3. Parallelism to the EXPRESS schema.

    Note that this specification prioritizes schema fidelity over human-readability or direct code integration.

  3. Overview of ifcJSON-4

    main

    ifcJSON-4 is a specification designed to represent IFC (Industry Foundation Classes) data in JSON format. It aims to bridge the gap between complex IFC EXPRESS/STP files and the modern requirement for JSON-based data exchange in construction and design projects.

    The specification is designed to be in sync with the IFC EXPRESS Schema, with a primary focus on:

    • Backward compatibility
    • Round-trip capability (converting between IFC and ifcJSON and back)
    • Parallelism to the EXPRESS schema

    While it adheres closely to the IFC schema, it also considers human-readability, code integration, and clear referencing structures. The current standard is based on IFC4 (specifically IFC4.3), with plans to follow IFC5 developments.

  4. Understand the origin of the BuildingSMART Test set files

    main

    The files in this directory are converted using a JAVA-based converter from the IFC.JAVA repository.

    The conversion process for the original SPF (.ifc) files involved:

    1. Collecting files from the official buildingSMART IFC4 ADD2_TC1 examples.
    2. Correcting files to ensure they are valid IFC files.
    3. Parsing them into a JAVA-based object model.
    4. Serializing them into XML and JSON using the Jackson library.

    Note on Data Structure: This specific conversion follows the EXPRESS schema of IFC and STEP files very closely. This means basic data types are wrapped in IFC-specific objects (for example, an integer will be represented as an IfcInteger object rather than a primitive type).

  5. Explore BuildingSMART Spec examples

    main

    This test set provides example files derived from the official BuildingSMART IFC schema specifications. It is designed to help developers test and compare IFC content across different syntaxes.

    For every .ifc (STEP) file provided, there are corresponding files in the following formats:

    • .ttl (RDF graphs in Turtle syntax)
    • .json (JSON format)
    • .xml (XML format)

    These files cover a wide range of EXPRESS concepts, including basic unit declarations, various geometric models (CSG, Brep, Tessellated), and structural elements (Beams, Columns, Walls, Reinforcing assemblies).

  6. Explore ifcJSON sample files

    main

    The Samples/ directory contains example files used for testing and demonstrating the ifcJSON format. These samples are categorized by their source IFC schema or test set:

    • IFC 2x3: Legacy examples used during development. Note that IFC 2x3 is not an official target schema for ifcJSON.
    • IFC 4.0: Examples converted using the Python-based converter.
    • IFC 4.3: Examples converted using the Python-based converter.
    • buildingSMART_TestSet_JAVA: JSON and XML versions of all available buildingSMART specification examples, generated using the JAVA-based converter.

  7. Handling empty, USERDEFINED, and NOTDEFINED values in ifcJSON

    main

    When constructing ifcJSON documents, you can include empty values, but it is encouraged to omit them to keep the data exchange efficient. The specification maintains NOTDEFINED and USERDEFINED as valid Enum elements.

    Best Practices:

    • Prefer omitting keys instead of providing null or empty strings for optional values.
    • Use NOTDEFINED for predefined types when a specific value isn't applicable.
    • Use USERDEFINED when providing a custom objectType.
    // Valid but contains unnecessary empty/null values
{
  "type" : "IfcDoor",
  "globalId" : "157c866c-9c08-4348-a0ed-4d57cd66c9e2",
  "name" : "A common door",
  "description": "",
  "overallHeight" : null,
  "overallWidth" : null,
  "predefinedType": "NOTDEFINED"
}

// Valid and preferred (omitting empty values)
{
  "type" : "IfcDoor",
  "globalId" : "157c866c-9c08-4348-a0ed-4d57cd66c9e2",
  "name" : "A common door"
}

// Recommended for specific values
{
  "type" : "IfcDoor",
  "globalId" : "157c866c-9c08-4348-a0ed-4d57cd66c9e2",
  "name" : "A common door",
  "description" : "Description of a standard door",
  "overallHeight" : 1.4,
  "overallWidth" : 0.7,
  "predefinedType" : "GATE"
}

  8. Structuring ifcJSON documents with tree structures

    main

    The ifcJSON structure is flexible: objects can be nested inline or referenced via globalId. However, it is recommended to use a tree structure (representing forward downward relationships) as much as possible to improve human readability. This structure should maintain all IFC objectified relationships (many-to-many, one-to-many, ternary, and n-ary).

    {
  "type" : "IfcProject",
  "globalId" : "22e66ddf-794d-40bb-8aa5-3dda450d8255",
  "name" : "Default Project",
  "isDecomposedBy" : {
    "type" : "IfcRelAggregates",
    "globalId" : "57bfe2d2-b505-4bba-8278-f867834a0be0",
    "relatedObjects" : [ {
      "type" : "IfcSite",
      "globalId" : "f55eaf97-145e-4431-b2f3-69f9634f244b",
      "isDecomposedBy" : {
        "type" : "IfcRelAggregates",
        "globalId" : "d3e2bc1a-4cdb-49ed-9c4a-c60c97949121",
        "relatedObjects" : [ {
          "type" : "IfcBuilding",
          "globalId" : "3ca7e585-4e3e-4969-a86f-f049f4fbde52"
        } ]
      }
    } ]
  }
}

  9. Defining object types with type, predefinedType, and objectType

    main

    ifcJSON follows the IFC EXPRESS schema for defining object types. You can use three specific attributes:

    1. type: Reserved for the IFC type name (e.g., IfcDoor).
    2. predefinedType: Used for a specific set of allowed values (e.g., GATE). These values should not be enclosed in dots (use "GATE", not ".GATE.").
    3. objectType: Used to define specific subtypes, often used in conjunction with predefinedType: "USERDEFINED".
    // Standard type definition
{
  "type" : "IfcDoor",
  "predefinedType" : "GATE"
}

// User-defined subtype definition
{
  "type" : "IfcDoor",
  "objectType" : "ThickMassiveWoodenDoor",
  "predefinedType" : "USERDEFINED"
}

  10. Representing Geometry in ifcJSON

    main

    Geometry in ifcJSON is structured similarly to STEP files, allowing for the inclusion of representation data, units, and geometric contexts. It typically involves a representation object containing representations, which in turn contain items (like IfcExtrudedAreaSolid) and their geometric definitions (like IfcPolyline or IfcCartesianPoint).

    "representation" : {
  "type" : "IfcProductDefinitionShape",
  "representations" : [ {
    "type" : "IfcShapeRepresentation",
    "representationIdentifier" : "Body",
    "representationType" : "SweptSolid",
    "items" : [ {
      "type" : "IfcExtrudedAreaSolid",
      "sweptArea" : {
        "type" : "IfcArbitraryClosedProfileDef",
        "outerCurve" : {
          "type" : "IfcPolyline",
          "points" : [ 
            { "type" : "IfcCartesianPoint", "coordinates" : [ 0.0, 0.0 ] }
          ]
        }
      },
      "depth" : 2.1
    } ]
  } ]
}

  11. Understand IfcLinearPlacement for alignment-based positioning

    main

    In IFC, IfcLinearPlacement is used to define the position of an object relative to a referenced space curve (such as an IfcAlignmentCurve).

    Instead of using absolute Euclidean coordinates, the position is determined by:

    1. A reference point (station) along the curve.
    2. Orientation and offsets in the longitudinal, lateral, and vertical directions.

    This is commonly used for infrastructure projects where elements (like IfcBuildingElementProxy cuboids) are placed along a road, rail, or pipeline alignment. This differs from IfcLocalPlacement, where Euclidean points are provided directly via x, y, and z values.

  12. Understand the NURBS IFC4 Sample File structure

    main

    The NURBS IFC4 sample folder contains IFC4 files demonstrating B-spline lines, surfaces, and solids exported from various applications. Each example typically consists of a pair of files to allow comparison between mathematical NURBS representations and tessellated (facet) representations:

    1. ExampleName.ifc: The IFC4 file containing the NURBS geometry.
    2. ExampleName.facet.ifc: The same example represented using tessellated facets (IFC4 ReferenceView or IFC2x3).
    3. ExampleName.md (Optional): Documentation regarding remarks, import problems, or responses related to that specific example.

    Examples are organized into subfolders named after the application that provided them, each containing an Application.md file.