Abstract: In example embodiments, techniques are provided for decoupling user access to infrastructure models from proprietary software that maintains and updates the infrastructure models. A backend application may include an infrastructure modeling backend module that, among other functions, handles communication with an infrastructure modeling frontend module of a frontend application that provides user access to the infrastructure model, infrastructure modeling hub services that maintain repositories for the infrastructure model, and an infrastructure modeling native module that creates, performs operations upon, and updates local instances of a database that stores the infrastructure model.

Abstract: In example embodiments, techniques are provided for decoupling user access to infrastructure models from proprietary software that maintains and updates the infrastructure models. A backend application may include an infrastructure modeling backend module that, among other functions, handles communication with an infrastructure modeling frontend module of a frontend application that provides user access to the infrastructure model, infrastructure modeling hub services that maintain repositories for the infrastructure model, and an infrastructure modeling native module that creates, performs operations upon, and updates local instances of a database that stores the infrastructure model.

Abstract: In one embodiment, techniques are provided for aligning source infrastructure data to be compatible with a conceptual schema (e.g., BIS) implemented through an underlying database schema (e.g., DgnDb). Data aligned according to the conceptual schema may serve as a “digital twin” of real-world infrastructure usable throughout various phases of an infrastructure project, with physical information serving as a “backbone”, and non-physical information maintained relative thereto, forming a cohesive whole, while avoiding unwanted data redundancies. Source-format-specific bridge software processes may be provided that that know how to read and interpret source data of a respective source format, and express it in terms of the conceptual schema.

Abstract: In one embodiment, techniques are provided for aligning source infrastructure data to be compatible with a conceptual schema (e.g., BIS) implemented through an underlying database schema (e.g., DgnDb). Data aligned according to the conceptual schema may serve as a “digital twin” of real-world infrastructure usable throughout various phases of an infrastructure project, with physical information serving as a “backbone”, and non-physical information maintained relative thereto, forming a cohesive whole, while avoiding unwanted data redundancies. Source-format-specific bridge software processes may be provided that that know how to read and interpret source data of a respective source format, and express it in terms of the conceptual schema.

Abstract: In example embodiments, techniques are provided to implement changeset conflict rebasing when performing conflict-detection and merging in an infrastructure modeling software architecture that uses an optimistic concurrency policy. Changeset conflict rebasing involves adjusting the pre-change values in a local changeset so they match post-change values of a remote version, rather an original base version, or removing changes from the local changeset entirely.

Abstract: In example embodiments, techniques are provided to implement changeset conflict rebasing when performing conflict-detection and merging in an infrastructure modeling software architecture that uses an optimistic concurrency policy. Changeset conflict rebasing involves adjusting the pre-change values in a local changeset so they match post-change values of a remote version, rather an original base version, or removing changes from the local changeset entirely.

Abstract: In one embodiment, techniques are provided for converting data items of a source repository that maintains a CAD description according to a first storage format to data items of an output repository that maintains the CAD description according to a second storage format. A converter gathers data items of the source repository and compares current condition information for them with condition information as of a last successful conversion maintained by a synchronization information record separate from the source repository. The converter determines one or more new or changed data items in the source repository since the last successful conversion, converts new or changed data items to the second storage format of the output repository, and stores them in the output repository, while skipping any unchanged data items. The converter further updates the synchronization information record to include the current condition information for data items in the source repository.

Abstract: In one embodiment, techniques are provided for converting a CAD description maintained in a first storage format (e.g., a file-based storage format) of a source repository to a second storage format (e.g., a relational database-based storage format) of an output repository. The techniques may, generate a single, coherent representation from spatially ambiguous “fragments” by generating an acyclic model graph for each graphical view, and then storing models of the acyclic model graph in the second storage format (e.g., the relational database-based storage format). The techniques may further produce a post-conversion CAD description that preserves human-readable names and information relationships related to levels by examining attachment specific copies of level structures (i.e. levels and attached levels) referenced from attachments, and generating from these categories and subcategories in the second storage format (e.g., the relational database-based storage format).

Abstract: In one embodiment, techniques are provided for aligning source infrastructure data to be compatible with a conceptual schema (e.g., BIS) implemented through an underlying database schema (e.g., DgnDb). Data aligned according to the conceptual schema may serve as a “digital twin” of real-world infrastructure usable throughout various phases of an infrastructure project, with physical information serving as a “backbone”, and non-physical information maintained relative thereto, forming a cohesive whole, while avoiding unwanted data redundancies. Source-format-specific bridge software processes may be provided that that know how to read and interpret source data of a respective source format, and express it in terms of the conceptual schema.

Abstract: In one embodiment, techniques are provided for converting a CAD description maintained in a first storage format (e.g., a file-based storage format) of a source repository to a second storage format (e.g., a relational database-based storage format) of an output repository. The techniques may, generate a single, coherent representation from spatially ambiguous “fragments” by generating an acyclic model graph for each graphical view, and then storing models of the acyclic model graph in the second storage format (e.g., the relational database-based storage format). The techniques may further produce a post-conversion CAD description that preserves human-readable names and information relationships related to levels by examining attachment specific copies of level structures (i.e. levels and attached levels) referenced from attachments, and generating from these categories and subcategories in the second storage format (e.g., the relational database-based storage format).

Abstract: In one embodiment, techniques are provided for converting data items of a source repository that maintains a CAD description according to a first storage format to data items of an output repository that maintains the CAD description according to a second storage format. A converter gathers data items of the source repository and compares current condition information for them with condition information as of a last successful conversion maintained by a synchronization information record separate from the source repository. The converter determines one or more new or changed data items in the source repository since the last successful conversion, converts new or changed data items to the second storage format of the output repository, and stores them in the output repository, while skipping any unchanged data items. The converter further updates the synchronization information record to include the current condition information for data items in the source repository.

Abstract: A method for resolving conflicts between versions of a file is provided. User input defining a boundary defining a conflict area are received. Conflicts between versions of a file are detected based on changes made to elements within the conflict area. The conflicts are marked in one of the versions of the file. The one version of the file is saved as the current version, including the conflicts. The other version of the file is saved in a history.

Abstract: Conventional file-based engineering design data for an engineering model are represented by a plurality of components. Each component has a unique identifier, a set of fields, each field having a data type and a data value, and a program which interprets and modifies the fields. The plurality of components are stored in a repository of a server. The repository also stores a history of any changes made to the components. A plurality of client computers are bidirectionally connected to the server. Each client computer may obtain the current version of the components and may send locally edited versions of the components back to the server to replace the current versions in the repository. At the client computer, the user interacts with the components using conventional file-based software.