Model Concept

Introduction

The Shared Object Model provides an environment for collaboration around information in a semantic object model and fosters real-time collaboration and data exchange by allowing multiple stakeholders to work concurrently within a single, unified seamless object model. It handles outgoing and incoming work sets from Trimble Connect Object Manager and manages collaboration through the reserve, release, and receive of tasks in work sets. 

There are four main concepts involved when creating a Shard Object model. 

• Location - WHERE is the data located

• Type Catalog & Objects - WHAT kind of data is the model describing

• Process & Task -   WHO did what when, and managing the content in the model  

Location

A Shared Object Model is usually defined with a specific public or custom Coordinate Reference System (CRS), but can also be defined with an arbitrary CRS.

Type Catalog

A type catalog is a structured collection of definitions and descriptions of objects and attributes that can be represented in a dataset. These object definitions can have different types of attributes both alphanumeric attributes, spatial attributes (geometry) and locational attributes can be included or not included in the object definition. In the type catalog. Relationships that are allowed between objects are also defined in the type catalog. The default Type Catalog for the Shared Object Model is based on the IFC 4x3 schema (Addendum 2).

A type catalog is essential for data standardization and interoperability, facilitating clear communication and data exchange between different systems and users.

Objects

Objects in the model are occurrences of objects according to the type definitions in the type catalog and may represent real-world objects or objects representing phenomena it makes sense to capture and locate, like a speed limit section located along the road network, or a geotechnical report for a given area.

Object occurrences may or may not have geometries, and it may or may not be located along the network. object model is based on a generic concept - “everything is a object”; e.g., Road Superstructure layer, Bridge,  Building, Wall, Window, Pipe, Noise, Traffic lights, Rails, Bus stop, Pile, etc.

Tasks

When a large model with many objects is to be shared between many people, this must be done in a way that allows each user to work with exactly their tasks, with associated data, and with a minimum of points of conflict with other users. 

Tasks are something someone - or a machine - needs to do. It can be a WorkOrder, a road design task, … anything. Is normally a hierarchy (WBS). One task can be input to another (creates dependency). Tasks provide the objects needed to do the task, and a way to add result data to the Shared Object Model and it provides the model sharing.

A task can be: 

• Import data 

  • to add a road corridor by importing a file 

  • add landscape objects and other infrastructure objects with their properties. 

• Creating a model presentation 

• Exporting information to a file where the input is independent on how the data was created..  

• etc..

With the central Shared Object Model information is shared among multiple users and they can access and reference information without duplicating data into files. To be able to do this search/query/filter is involved in all operations you as a user is doing. In the workset of a  Shared Object Model, you can query on any: task, object, attribute and property, relationship, or location (both area and from/to). 

To have control over your queries these are tied to a task and all the work you are doing when interacting with the workset of a Shared Object Model uses the process and task concept. Tasks are a piece of work that someone does. 

How to alternately address a user's need to work in isolation and then share the data with other users:

The task concept is central to how the Shared Object Model solves the multiple users approach to effectively handle large models so people in different disciplines can work in parallel with their respective tasks, and at the same time be able to easily integrate the information into the same model for control and coordination. 

In a file-based world, things have gone well: Each user - each their own file, and no "conflict points". That is to say; the conflicts have arisen anyway, as a result of the fact that the data has not been synchronized in the same model, but has lived in separate and independent files.

In many ways, the task takes care of the function of a file: The file knows its tool via the file extension - and the data is, after all, the content of the file. The tasks in the task model also do that, but with the advantage that the information is not stored in the task: The task references "its" input and result objects in the object model. Thus, the objects are also available for other tasks, such as presentations, analyses, and other successor workflows.