Construction¶

Introduction¶

Gemini Terrain covers the contractor's needs for collecting staking data from discipline models, documenting quality of execution, reporting and documenting quantities for settlement/measurement certificates and SOSI delivery to FKB and NVDB.

The contract that the contractor has entered into with the client consists of a number of contract posts. These can be delivered to the contractor as XML files according to the NS3459 standard, imported into Gemini Connected and made available in Gemini Terrain. In Gemini Terrain, the contractor can then link quantities in application layers (pcs, m, m², m³) and mass types (m, m², m³) to these contract posts.

Each contract post should result in a measurement certificate. This must be in place to get final settlement for the contract post. The measurement certificates represent a significant workload for contractors. Creating the actual measurement certificate is simple, but structuring the basis is demanding. By utilizing the capabilities in Gemini Terrain, it's possible to streamline large parts of this work.

Typically, a construction project is staffed with a contract manager. This person is responsible for collecting a large amount of data that needs to be processed and prepared as documentation for the client.

Documentation basis

The illustration shows some of the documentation basis that is collected and what is prepared.

This section describes typical tasks that we can solve with Gemini Terrain:

Collecting staking data from discipline models
Geometric control
Documentation of quantities in application layers
Documentation of masses between layers
Documentation of quantities in roads
Documentation of quantities in trenches
Documentation of quantities in tunnels
SOSI delivery to FKB and NVDB

Before we address the different tasks, let's take a closer look at the project menu in Gemini Terrain. The program is flexible regarding how we organize data in our project. We can have one drawing with many application layers or several drawings with fewer application layers. One might ask if it's sufficient to have one drawing for designed data and measured data. The drawback is that there will quickly be many application layers in the vertical list field. If the job is of limited scope, this could of course be a viable solution.

For road projects with the Norwegian Public Roads Administration as the client, we can for example use the project menu more actively as shown below. We can then create a drawing for each discipline model. This could give the following suggested drawings in the project menu:

001: Base models
010: Discipline model Road
021: Cross sections C-91
022: Cross sections C-92
...
100: Discipline model Structures
101: Presentation 1
102: Presentation 2
...
150: Discipline model Tunnel
151: Presentation 1
152: Presentation 2
...
200: Discipline model Water & Sewer, trenches and drainage
201: Presentation 1
202: Presentation 2
...
250: Discipline model Rock support and geotechnical structures
251: Presentation 1
252: Presentation 2
...
300: Discipline model Signs, signals and markings
301: Presentation 1
302: Presentation 2
...
350: Discipline model Road equipment
351: Presentation 1
352: Presentation 2
...
400: Discipline model Cable conduit systems
401: Presentation 1
402: Presentation 2
...
450: Discipline model Technical installations
451: Presentation 1
452: Presentation 2
...
500: Discipline model Landscaping measures
501: Presentation 1
502: Presentation 2
...
550: Discipline model Regulatory surfaces
551: Presentation 1
552: Presentation 2
...
600: Discipline model Environmental measures
601: Presentation 1
602: Presentation 2
...
650: Discipline model New property and rights conditions and land acquisition
651: Presentation 1
652: Presentation 2
...
900: Interdisciplinary model (Coordination model)
...
950: As-built model

In principle, we can as mentioned add all application layers in the same drawing. However, it is more practical to divide the project menu into disciplines as shown above. In the terrain model drawing for each discipline, we will then have application layers with for example:

Designed data
Collected staking data
Data for geometric control
Data for settlement (linked with contract post code)
Data for SOSI delivery (FKB/NVDB)

Between each discipline drawing, space is allocated for various presentation drawings related to the discipline, cross-section drawings for roads, presentation drawings for geometric control, and SOSI delivery.

Note

As we know, application layers are global. This means, for example, that we can have a drawing (interdisciplinary model) that compiles all designed discipline models.

See also the Construction chapter in the example collection for implementation.

Construction¶

Introduction¶

Project menu in Gemini Terrain¶

Suggested organization of project menu¶