Model Concept

Introduction

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 -   Representing the work -WHO did what when  

Location

A Shared Object Model are 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 (geometry) attributes and locational attributes can be included or not included to the object definition. In the type catalog. Relationships that is 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 catalogue is essential for data standardization and interoperability, facilitating clear communication and data exchange between different systems and users.

Objects

Objects in the model is occurrences of objects according to the type definitions in the type catalog, and may represent real-world objects or objects representing phenomena's 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 occurences 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”; eg. 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, relationships, 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 the 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.