Does the client need to view the data or use it?
Point clouds and survey outputs reach very different people: engineers who load them into CAD or modelling software, GIS teams who add them to a map, project managers who only want to look, and agencies who keep them on record. Before choosing a delivery method, settle which of these each recipient is.
| The client wants to | What they need | What works |
|---|---|---|
| Look at the result and take a few measurements | A browser view of the point cloud or model | A web-based point-cloud viewer or the processing platform's sharing page |
| Load the data into their own software | The original files: point clouds, orthomosaics, elevation models, reports | A file delivery they can download completely, with structure kept |
| Keep a record for compliance or the project file | The files plus proof of what was delivered and when | A file delivery with a download record |
| Send data back to you | A simple way to upload without an account | An upload link or a shared inbox |
Many projects need both: a viewer link for the people who only look, and the original files for the people who do the engineering.
Package the deliverable so it stands on its own
- Keep a clear folder structure: point clouds, imagery, elevation models, reports and metadata in separate folders, with tiles named consistently.
- Include a short readme: project, capture dates, coordinate reference system, vertical datum, units, accuracy statement and who to contact.
- Add a file list with sizes, so the client can check they received everything.
- Use the formats the client asked for. LAZ is a lossless compressed form of LAS and is usually much smaller; confirm the client's software reads it before relying on it.
- Send the whole deliverable as one delivery, not a series of separate links the client has to collect.
How the common delivery options compare
| Option | Works well when | Watch out for |
|---|---|---|
| Cloud drive share link | The deliverable is modest and the client is comfortable with that service | File and storage limits, links that never expire, little record of who downloaded what |
| The client's own portal or SFTP server | The client requires it | Their limits, their upload speed, and a different process for every client |
| Shipping a drive | The dataset is too large for either side's connection | Days in transit, lost drives, no record until it arrives |
| Web point-cloud viewer | Recipients only need to look and measure | Not a substitute for the original files when engineers need them |
| Managed file delivery | Deliverables are large, recurring or sensitive, and you need a record | Choose one where recipients need no account or paid seat |
Controls worth having on any delivery link
- Who can open it: named recipients, or anyone with the link plus a passcode sent separately.
- When it stops working: an expiry date long enough for the client to download, and no longer.
- What it allows: download of this delivery only, not browsing your other projects.
- A record: when the delivery was viewed and downloaded, and by whom.
- A way to withdraw it: revoke access if the link went to the wrong person.
Confirm the client actually received it
- 1Check the download record rather than waiting for the client to say something is missing.
- 2Ask the client to compare the file count and total size against the file list in the delivery.
- 3Keep the delivery available until they confirm, then let it expire.
- 4Record the delivery date and what was delivered for the project file.
Where Ripton Cloud fits
In Ripton Cloud, a deliverable is sent as one package with its folder structure kept. Named recipients get a scoped link and download from a browser without an account. For someone who is not a named recipient, set a package passcode and an expiry, then share the public download link and the passcode separately. The package's Activity tab records external views and downloads. Clients can send data back through an upload link or a Shared Inbox.
External recipients and guests do not use a paid seat on any plan. Every transfer is encrypted, and the data stays on the Ripton node you run on your own servers or cloud account.