|Axis Aligned Bounding Box.
|Auxiliary Coordinate System. Views may choose to use an Auxiliary Coordinate System to show coordinate information with a different orientation and units.
|The part of an iTwin.js app that is concerned with accessing data in a briefcase. See frontends and backends. See learning about backend code.
|Base Infrastructure Schema. Defines the hierarchy and organization of information about an infrastructure asset. BIS is relevant outside of iModels, but all information stored in an iModel conforms to BIS.
|The base BIS Domain for iModels. All ECClasses stored in an iModel must derive from a BisCore class.
|A file holding a copy of an iModel. It contains data from Changesets as well as local changes. See BriefcaseDb.
|A geographic coordinate system based on lat/long/height. If an iModel is geo-located via an EefLocation, Spatial Coordinates may be converted to Cartographic coordinates.
|A property of a GeometricElement that "categorizes" its geometry. That is, every GeometricElement is "in" one and only one Category. The visibility (on/off) of a category may be controlled per-view. Categories are similar to levels in DGN, layers in DWG, and categories in RVT. Note that Categories are not relevant for Elements that are not GeometricElements. Category is a subclass of DefinitionElement.
|A named group of Categories displayed in a View. Many ViewDefinitions may refer to the same CategorySelector.
|A group of changes to an iModel. Changesets are created whenever an Briefcase is modified and reflect the union of all Additions, Deletions, and Modifications over a period of time. Changeset are assigned an identifier when they are uploaded to iModelHub and every Changeset stores the identifier of its parent Changeset. In this way the chain of Changesets for an iModel in iModelHub forms its "timeline of changes".
|A summary of the changes in a Changeset in the form of ECClasses and ECProperties.
|An optional three part human readable identifier for an Element. A code consists of a CodeSpec, CodeScope, and CodeValue. The combination of all three parts must be unique within an iModel.
|A Code Scope determines a scope for uniqueness for the code value. For example, a scope may specify the whole iModel, only within a certain Model, within an assembly, etc. For a given CodeSpec and CodeScope, all CodeValues must be unique.
|A CodeSpec defines the specification (i.e. type) of a code. Often the specification is defined by some external system that enforces conventions, consistency, and validation. A CodeSpec captures the rules for encoding and decoding significant business information into and from a CodeValue. iModels hold a table of the known CodeSpecs, defined by the CodeSpec ECClass, and Elements refer to one of them by Id.
|A human-readable string with the name of an Element. CodeValues are formatted according to the rules of its CodeSpec.
|A subclass of InformationContentElement that holds configuration-related information that is meant to be referenced (i.e. shared) by other Elements.
|A named set of choices for the way Geometry is displayed in a view. Many ViewDefinitions may refer to the same DisplayStyle.
|A named set of ECClasses that define the information for a particular discipline or field of work. All classes in a Domain ultimately must derive from a BisCore class. The ECClasses for a Domain are defined in a ECSchema file, hence the terms Domain and ECSchema are often used interchangeably.
|A 2d model that holds drawing graphics. DrawingModels may be dimensional or non-dimensional (i.e. unitless).
|An abbreviation for Entity Classification. This prefix is used to refer to the metadata system of iModels.
|A named set of properties and relationships that defines a type of object. Data in iModels are defined by ECClasses.
|A SQLite database conforming to the rules of EC. iModels are a type of ECDb.
|The position and orientation, in Earth Centered Earth Fixed (also known as ECR "earth-centered rotational") coordinates, of the origin of the Spatial Coordinate System of an iModel.
|A named member of an ECClass.
|A named type of relationship and cardinality between instances of ECClasses.
|A named group of ECClasses and ECRelationships.
|A superset of SQL that uses ECClass and ECProperties names in place of table and column names.
|The base class in Bis for an Entity with a Code. Elements also have an ElementId, a FederationGuid, and an ElementUserLabel. There is also a backend TypeScript class called Element.
|An ECClass that holds information related to (and owned by) a single Element. Semantically, an ElementAspect can be considered part of the Element, but defined independently. Thus, ElementAspects are deleted when their owning Element is deleted.
|A TypeScript class that holds the properties of an Element in the frontend. See ElementState.
|The names and types of the ECProperties and ECRelationships of an Entity ECClass.
|A physical or non-physical object in the real world, defined by an ECClass.
|An optional 128 bit [GUID] for an Element. Generally it is intended that FederationGuid are assigned by external systems and are held in iModels to federate Elements to their external meaning.
|A named string or blob that holds metadata about an iModel. FileProperties are meant to be accessible directly from SQLite and are the only data in an iModel not defined by an ECClass. For example, thumbnails are stored as FileProperties.
|The part of an interactive app that is concerned with displaying data and user interaction. See frontends and backends. See App frontends
|An 8-point truncated pyramid that defines the volume of space visible in a View. The front and back planes must be parallel and their centers must align at right angles.
|A subclass of Element that can include geometry (in its GeometryStream.) Only GeometricElements are visible in Views.
|A subclass of Model that can hold GeometricElements.
|A named GeometryStream that can be shared by many GeometricElements.
|A collection of geometric primitives that describes the geometric properties of a GeometricElement. Individual members of GeometryStream may be on different SubCategories and may reference GeometryParts.
|Globally Unique Identifier
|An abbreviation for Internationalization.
|A TypeScript class that holds hexadecimal-encoded string for a 64-bit Id.
|A TypeScript string which has been normalized using the Id64 API to represent a 64-bit Id.
|A distributed relational database holding information about an infrastructure asset defined in BIS. Many copies of an iModel may be extant simultaneously, each held in a Briefcase and synchronized via Changesets from iModelHub.
|The administrator class for frontend applications. By subclassing IModelApp, applications can control the behavior of the frontend services.
|A TypeScript class in the frontend that represents the connection to the iModel on the backend.
|A cloud service that coordinates access to iModels. It grants permission to approved iTwin.js applications to access Briefcases of iModels on behalf of a authorized user. It also accepts and distributes Changesets to form the immutable and authoritative timeline of changes for an iModel.
|An infrastructure digital twin of an asset or project. iTwins are comprised of data from many sources, some of which are owned by the iTwin, and some of which are referenced by the iTwin. For example, an iTwin may hold Reality data (e.g. reality meshes, point clouds, geotechnical data, etc.) and one or more iModels. It may reference IOT data, GIS data, maintenance, and other IT databases. iTwins have an iTwinId, used to identify it in iTwinHub. iTwins may nest (that is, iTwins may have a parent iTwin), for example for projects and sub-projects.
|A GUID for an iTwin.
|An abbreviation for Localization.
|A named pattern that is repeated along a path when it is displayed to represent the meaning of the path.
|The right to modify an element. See LockControl.
|Process of applying changes from a Changeset to a Briefcase.
|A set of Elements used to describe another Element (its ModeledElement) in more detail. Every Element is contained in one and only one Model via a ModelContainsElements relationship. In this manner, Models form a hierarchy of Elements. There are many subclasses of Model (e.g. PhysicalModel, FunctionalModel, etc.)
|An Element that is sub-modeled or broken down in more detail by a Model. Note that the name of a Model is the name of its ModeledElement, and the ParentModel of a Model is the Model of its ModeledElement. The ModeledElement mixes-in
ISubModeledElement and may also be referred to as a "SubModeledElement"
|A named set of Models that are visible in a View. Many ViewDefinitions may point to the same ModelSelector.
|A version that is given a name on iModelHub to distinguish it amongst other versions due to its significance (e.g. a milestone, a review version).
|Normalized Plane Coordinates. A coordinate system for Frustums where each dimension [x,y,z] is normalized to hold values between 0.0 and 1.0 inside the Frustum. In NPC, [0,0,0] is the left-bottom-rear and [1,1,1] is the right-top-front of the Frustum.
|A derived property of Model that is equal to the Model of its ModeledElement.
|A subclass of SpatialModel that holds PhysicalElements.
|The volume of interest for an iModel's Spatial Coordinate System. All spatial elements in an iModel must be completely inside its Project Extents.
|iTwin.js uses the convention that the members and types of a JSON wire format are expressed in TypeScript by an interface or type alias with the suffix Props (for properties). E.g.
|Process of downloading Changesets for a Briefcase that are newer than the last Changeset merged into that Briefcase.
|Process of uploading local changes from a Briefcase to iModelHub in a form of a Changeset. It is necessary to pull and merge any newer changesets from other users before pushing.
|A digital representation of an asset generated from captured data of the physical asset, for example a 3D photogrammetric mesh model or a point cloud of a building.
|An Element in the iModel that describes (in text) the asset modeled by an iModel. There is always one and only one RootSubject. All information in an iModel will have some relationship to the RootSubject, making it the root of a table of contents.
|Remote procedure call. Allows a client to invoke an operation in a service. Web apps use HTTP to implement RPC calls, while desktop apps use pipes.
|An interface exposed by a service and callable by clients via RPC. See RpcInterface for more information.
|A tool for managing multiple NPM packages within a single git repository.
|A digital representation of a sheet of paper. Sheet Models are 2d models in bounded paper coordinates. SheetModels may contain annotation Elements as well as references to DrawingViewDefinitions. or SpatialViewDefinitions.
|A static point-in-time representation of the state of an iModel.
|Spatial Coordinate System
|The 3d coordinate system of an iModel. The units are always meters (see ACS). The origin (0,0,0) of the Spatial Coordinate System may be oriented on the earth via an EcefLocation.
|A subclass of GeometricModel that holds 3d Elements in the iModel's Spatial Coordinate System.
|A subclass of ViewDefinition that displays one or more SpatialModels.
|A subdivision of a Category. SubCategories allow GeometricElements to have multiple pieces of Geometry that can be made independently visible and styled. It is important to understand that a SubCategory is not a Category (i.e. Categories do not nest) and that a SubCategory always subdivides a single Category.
|The appearance (e.g. color, weight, style, etc.) of geometry on a SubCategory. Every SubCategory has a default SubCategoryAppearance and Views can optionally override its values.
|A TypeScript class in the frontend that implements a technique for tentatively snapping to interesting points in a View. Usually the TentativePoint action is mapped to the center mouse button.
|A TypeScript class that holds a run of unicode-encoded text that all has the same size, font, style, etc.
|A small JPEG or PNG encoded image that provides a rough snapshot of an Element. Some thumbnails (e.g. view thumbnails and the overall iModel thumbnail) are stored as FileProperties.
|A TypeScript class in the frontend that associates a ToolId with an action. Subclasses of Tool can react to user input.
|A short string that unambiguously identifies a Tool.
|An optional string that holds a user-assigned alias for an Element. UserLabels are not enforced to be unique.
|An immutable state of iModel as of a specific Changeset. It contains data from all Changesets up to specified one and contains no local changes. See Briefcase for comparison.
|An abstract concept that forms a relationship between a rectangular region on a screen and content in an iModel. All of the classes involved in that mapping are collectively referred to as a View.
|A subclass of DefinitionElement that holds the persistent state of a View. There is also an eponymous Typescript class in the backend.
|A TypeScript class in the frontend that connects an HTMLCanvasElement to a ViewState.
|A TypeScript class in the frontend that holds a copy of the state of a ViewDefinition. A ViewState is modified by viewing operations (e.g. pan, zoom, rotate, etc.). There are a parallel set of subclasses of ViewState for the subclasses of ViewDefinition.
|The JSON representation of objects that must be used when transferring data in iTwin.js. See Props.
Last Updated: 12 February, 2024
Found something wrong, missing, or unclear on this page? Raise an issue in our repo.