Status Scope of services. Nothing on this site is a record of completed work.
Practice BIM & digital delivery
Scan to model
What is done with a point cloud somebody else captured: existing-condition and as-built models, each stating its tolerance and what the scan could not see.
A point cloud is a measurement of surfaces. A model is a set of decisions about what those surfaces are. Everything that goes wrong between the two happens in that gap: a forty-millimetre bow read as a bow or as a modelling tolerance, a column boxed out in plasterboard modelled at the size of the box, a slab soffit inferred from one scan position that could not see it.
Whose scan it is
The cloud arrives with the job. No survey is carried out from this site, no scanning equipment is operated and no measurement is taken on a site here — the capture belongs to the surveyor or the contractor who made it, and so does its accuracy. What has to arrive with the cloud is what makes it usable: the coordinate system and the control it was aligned to, the alignment tolerance whoever captured it reports, where the scan positions were and therefore what was in shadow, the date of capture, and what has changed on the site since. A model can be no more accurate than the cloud under it, and that number is somebody else's to state. What a model built from one is then relied on for — coordination, documentation, an as-built record — is the subject of BIM & digital delivery, and every one of those uses inherits this tolerance.
What is modelled, and to what tolerance
Modelling from a cloud is deciding, element by element, what a surface is and how far the model may depart from it. Those decisions are stated rather than left inside the file: the tolerance each class of element was modelled to, whether a member sits at its measured position or has been straightened onto the nearest grid line, and whether a departure was carried into the model or recorded beside it. Straightening is often the right answer, because a frame drawn with every real bow in it is unusable for design. A straightened model that does not say it has been straightened is the problem — it will be trusted to a millimetre it never had, by somebody who was not in the room.
What a scan cannot show
A scanner records what it can see, which excludes most of what a structural decision turns on. Reinforcement inside concrete, a connection behind cladding, the far face of a wall scanned from one side, the thickness of a slab, a weld under paint, the bearing at the top of a column in a ceiling void: none of it is in the cloud. Each is either excluded from the model and said to be excluded, or modelled as a stated assumption with its basis named — an old drawing, an opening-up somebody else carried out, a dimension taken on site by the party that was there. A model that fills those in silently is the most expensive document on the job, because nothing about it looks wrong.
Deviation, and the as-built question
Where a design model already exists, the useful output is usually not a second model but the difference between the two: element by element, the magnitude and direction of the departure, at the location it occurs, set against the tolerance the specification allows. A deviation list is something an engineer can act on. A design model quietly dragged to match the cloud is a record of nothing, because the departure it was correcting has gone with it. An as-built model is the same discipline applied at the end of a job rather than the start: built from the records the parties issue and from a cloud captured on a date, and stating both — because a model that does not say what it was assembled from and when is not an as-built record, it is a drawing with a newer name.
Pending confirmation
Each of these is held until a fact is confirmed, and named here rather than written around.
HELD — NOT PUBLISHED
- The formats a point cloud can be sent in. This site publishes the formats a job's files move both ways in, and no point-cloud format is among them, so a cloud reaches a job by arrangement rather than through the enquiry form until the owner confirms which formats to add.
Deliverables, standards and what you supply
- What you receive
- An existing-condition model built from the point cloud you supply, stating the tolerance each class of element was modelled to
- A statement of what was excluded from the model and what was assumed, naming the basis for each assumption
- A deviation list: element, magnitude, direction and location, set against the tolerance the specification allows
- An as-built model, built from the records the parties issue and from a point cloud captured on a stated date
- The model in IFC and in the format it was built in, on the coordinate system the cloud was aligned to
- What you supply
- The point cloud, and the coordinate system and control it was aligned to
- The alignment tolerance reported by whoever captured it, and the date of capture
- The scan positions or coverage plan, so what was in shadow is known rather than guessed
- The design model or drawing set the capture you supply is to be compared against, where one exists
- What the model is for: design against existing conditions, a deviation check, or an as-built record
Continuous line: Seimora’s scope Dashed line: By others
Which packages a job’s files can be exchanged with, and in what form, is set out once on the standards page.
What leaves
- Hands on to
- Model coordination
The existing-condition model, its deviation list and the tolerance each element was modelled to go to model coordination, so a new frame is checked against the building that is there rather than against the one the old drawings show.
Start with this work
Send the model or the drawing set and say which of it you want. A single page of scope is a normal way to start; the other practices are there if the job needs them later.