A spatial data delivery platform is software that takes the spatial files you produce — point clouds, orthomosaics, 3D models, scan data — and makes them viewable in a client’s browser, presented through a branded portal, with a record of who accessed what and when. It is not a file storage tool. It is not a viewer. It sits at the intersection of both, with delivery workflow built around it.
The distinction matters because the two problems — storing files and delivering data — are genuinely different, and solving one does not solve the other.
The problem that file storage does not solve
Dropbox, Google Drive, SharePoint, and WeTransfer are excellent at what they do: storing files and making them downloadable. They solve the transfer problem completely. If you need to get a 4 GB LAZ file from your desktop to a client’s hands, any of them will do it.
But delivering a LAZ file to a client is not the same thing as delivering the data it contains. To access the data, the client needs to open the file — which requires CloudCompare, QGIS, Autodesk Recap, or another specialist application they almost certainly do not have installed.
The result is a delivery that technically succeeded and practically failed. The file arrived. The client cannot read it. The point cloud that took a day to capture and several hours to process sits in a Downloads folder, unopened, because there is no application on the client’s computer willing to open a .laz file.
This is not an edge case. It is what happens by default when a surveyor sends a Dropbox link. The client opens the PDF report. They try to open the LAZ, hit an error, and give up. The most valuable deliverable goes unseen.
What a spatial data delivery platform actually does
A spatial data delivery platform is built around three distinct layers that address three distinct problems.
Layer 1 — The viewer: can your client open it?
The foundation is a set of browser-based viewers for spatial formats. Each format requires a different rendering approach:
| Format | Viewer technology | What the client sees |
|---|---|---|
| LAS, LAZ | Potree (WebGL octree) | Interactive 3D point cloud — orbit, zoom, measure |
| GeoTIFF | MapLibre / Leaflet | Orthomosaic or elevation model on an interactive map |
| IFC | Three.js / IFC.js | 3D BIM model with element selection and metadata |
| OBJ, GLB | Three.js | Textured 3D mesh — rotate, zoom, explore |
| E57 | Converted and rendered via Potree | Terrestrial scan data in the browser |
| DXF | Vector renderer | CAD drawing with pan and zoom |
| 360° panoramas | Pannellum or equivalent | Immersive equirectangular view |
| Gaussian Splats | WebGL splat renderer | Photorealistic 3D scene from NeRF-adjacent capture |
| Video | Standard video player | Drone footage or inspection video |
| Inline reader | Report or certificate, no download required |
The viewer layer means a client who has never heard of CloudCompare, QGIS, or Autodesk Recap can fully engage with their deliverable. They click a link. The data loads. They explore it.
Layer 2 — Delivery: does it look professional?
File storage tools are generic. When a client receives a Dropbox notification, the experience says “Dropbox,” not “your surveying company.” The interface is Dropbox’s blue logo, Dropbox’s navigation, Dropbox’s chrome around your data.
The delivery layer of a spatial data delivery platform provides:
- Branded portals: Your logo, your colour scheme, your domain, your framing. The client experience is your brand, not the platform’s.
- Organised presentation: Files grouped by site and capture session, with context about what each deliverable represents. Not a flat folder of filenames.
- A professional handoff: The client receives a link to “your survey from [Your Company]” — not “Alex shared a folder with you on Dropbox.”
This matters commercially. The way you present your deliverable affects how clients perceive the value of what they received. A surveyor who sends a branded portal with an interactive point cloud and an orthomosaic on a map is visibly different from one who sends a Dropbox link with a folder of files nobody can open.
Layer 3 — Record: is there an audit trail?
File storage tools track file events at the system level. They can tell you a file was downloaded, but not whether it was viewed, not who viewed it by name, and not what they did within the viewer.
The record layer of a spatial data delivery platform captures:
- Per-view logging: Who opened the portal, when, from what IP and location
- Per-file events: Which files were opened in the viewer, which were downloaded
- Delivery confirmation: A verifiable record that the client accessed the deliverable — useful for contract disputes, payment terms tied to delivery, and professional liability
- Ongoing access history: If the client returns to the portal three months later, that event is logged
For professional services where delivery is a contractual milestone, an audit trail is not a nice-to-have. It is the record that something was delivered, received, and accessed.
Who needs one
The simple test: are any of your deliverable formats specialist spatial files that your client does not have the software to open?
If you are a surveyor, your core deliverables — LAS/LAZ point clouds, GeoTIFF orthomosaics, E57 scan data, DXF drawings — require specialist software on the client side. That is not universal. Most of your clients are project managers, property owners, civil engineers, or infrastructure operators who run Microsoft Office, maybe AutoCAD, and nothing else.
If you are a drone operator, your processed outputs from Pix4D, Metashape, or DJI Terra include LAZ point clouds and GeoTIFF orthomosaics. Delivering them via Dropbox means delivering files most clients cannot open. See our guide on how to deliver drone survey data to clients for the specific workflow.
If you are a BIM consultant or scanning company, your IFC models and E57 scan datasets require Navisworks, Revit, Cyclone, or equivalent software on the client side — software a substantial portion of your clients do not have.
If you are a photogrammetry specialist, your OBJ meshes, textured GLB models, and 3D Tiles outputs are viewable in specialist software that your clients often lack.
The common thread is not industry or scale. It is file format. If you deliver formats that require specialist software, your clients need a viewer — and the professional version of that viewer is part of a delivery platform that also handles branding and audit.
The distinction from adjacent tools
Cloud storage (Dropbox, Google Drive, OneDrive, S3): transfers and stores files. Provides no viewer for spatial formats. No delivery workflow, no branded portal, no spatial audit trail.
Standalone viewers (Potree, CloudCompare, iTwin Viewer): render spatial data but do not handle file transfer, delivery workflow, or client-facing branding. Typically require technical setup to deploy.
Project management platforms (Procore, Autodesk Construction Cloud, Aconex): manage the full construction project lifecycle — RFIs, submittals, document control. Some have basic file preview for common formats, but do not have browser-based viewers for LAS, LAZ, GeoTIFF, or E57. Spatial data uploaded to these platforms is typically download-only.
A spatial data delivery platform sits in its own category: purpose-built for the delivery workflow between a spatial data professional and their client, with viewers, branding, and audit built in as first-class features.
What makes a good implementation
The best implementations are invisible to the client. They click a link, the data loads, and they can explore it without friction. The technology disappears. The data is just there.
On the professional side, the best implementations reduce the friction of delivery — multipart upload for large files, automatic format detection, one-click portal creation — so that the overhead of professional delivery is minimal. The surveyor should not have to do extra work to deliver professionally. The platform should handle the complexity.
Swyvl is built around this principle: upload your deliverables, and Swyvl classifies each file, assigns the correct viewer, and presents everything through a branded portal. The point cloud loads in Potree. The GeoTIFF renders on an interactive map. The PDF appears inline. The audit trail runs automatically.
The delivery gap in spatial data is real. File storage tools are not going away — they are excellent for what they do. But they do not solve the viewing problem, and the viewing problem is what determines whether your client actually engages with the data you deliver.