You plan the mission in UgCS.
The delivery has to be able to tell that story.

In short: UgCS lives before the flight, not after it. It calculates your flight lines, camera triggering and terrain-following altitude from your camera and your target ground resolution, and it saves that route so you can fly it identically next year. It does not process, and it does not deliver — those are two separate steps afterwards. What tends to get overlooked: the parameters you set here are not a technical detail, they are the evidence behind your deliverable.

What you fix before take-off cannot be repaired afterwards

Setting up a photogrammetry mission in UgCS is a short sequence: new route, pick the drone, choose the Photogrammetry route type, draw the survey area, pick the camera — and UgCS calculates the flight lines. The choice that matters most comes immediately after, and it can be made in either direction:

• You state the GSD — say 2 cm per pixel — and UgCS calculates the altitude required to achieve it.
• You state the altitude and UgCS shows the GSD that follows from it.

The arithmetic behind it is simple — height above ground = (focal length × GSD × sensor pixel count) / sensor dimension — but its meaning is not. GSD is the promise about what is visible. At 2 cm per pixel, a 5 mm crack is not a finding, however crisp the photo looks. Upscaling later invents no detail that was never captured; if the resolution was too coarse for your client's question, the flight was not the answer to it.

For overlap, UgCS starts from 80 % along the flight line and 70 % between passes. On flat, high-contrast ground you can come down; over vegetation, water, reflective roofs or a complex structure you go up, because a reconstruction that falls apart costs you a second flight.

The altitude mode: this is where comparability is lost

UgCS lets you choose how altitude is held during the flight, and that choice decides whether one GSD figure applies to the whole job:

AGL is the right choice for most survey work for exactly one reason: it keeps ground resolution equal across the area. Fly AMSL over sloping ground and your 2 cm per pixel is an average and nothing more — coarser on the high side, finer on the low side. Smart AGL exists for the cases where ordinary AGL cannot track the terrain fast enough, such as a cliff face or a quarry wall; it is not included in every licence, so check your own version against the SPH Engineering licence overview.

For your deliverable this means: the altitude mode belongs with the GSD figure. "2 cm/px, AGL" is a statement about the whole map. "2 cm/px" on its own is a statement about somewhere.

Repeatability: on inspection work, that is the product

On a one-off survey, the flight is the job. On inspection work the series is the job — and a series only exists if the flights are comparable with each other. SPH Engineering puts it bluntly in its own inspection guidance: every inspection of the same asset has to use the same flight path, the same altitude, the same overlap and the same GSD.

That is why you save the route rather than redrawing it every quarter. A saved route, shared with a second pilot, is the difference between "we flew it again" and "we can compare". Without that discipline, two captures of the same façade are two nice photo sets in which you cannot point at anything that changed, because you don't know whether the difference is in the wall or in the flight height.

And then the step that is almost always missing: your client sees none of that care unless you deliver it too. Three flights sharing a route name, with three capture dates, together in one portal, are visibly a monitoring series. The same three flights as three download folders are the same file three times with a different date on it. The work was identical; only the second version sells the follow-up contract.

Vertical structures: Vertical Scan

For façades, towers, dams and silos a nadir grid does not work — that is what the Vertical scan tool in UgCS is for. You draw a polyline as the projection of the vertical plane, enter the distance to the façade, the minimum and maximum height above ground and the overlap, and pick your camera from the payload list. UgCS lays a flight over that which keeps the camera perpendicular to the surface.

Two practical points from the same guidance. First, the pattern: if the object is taller than it is wide, choose the vertical pattern, otherwise the horizontal one — that saves turns and therefore battery. Second, why the standoff distance carries so much weight: a constant distance to the surface is what keeps the GSD on that façade constant. That is precisely what makes a crack width comparable between two years.

For cylindrical objects — masts, chimneys, cooling towers — there is also Circlegrammetry, a circular oblique pattern. SPH Engineering reports 64 % less flight time than a classic double grid in its own field tests; treat that as a manufacturer's figure, not as a guarantee for your object.

Terrain: don't let the default elevation data set your altitude

Terrain following is only as good as the elevation model underneath it. UgCS works from SRTM data at roughly 30 m resolution by default — usable across a landscape, too coarse for a quarry, an embankment or a dyke. You can import your own DEM or DSM as a GeoTIFF, and on exactly that kind of terrain it is the difference between a plan and a risk.

Two screens that verify it before you leave:

• Elevation Profile — draws your flight path against the terrain. This is where you see whether terrain following does what you think it does, and whether there is a height difference you missed on the map.
• Route Log — gives you area, number of passes, waypoint count and the total shot count. That last figure is not only your storage and processing estimate: it is also your most honest prediction of how much material has to pass through your delivery.

Thermal: the planning decides whether it stays measurable

A thermal mission hangs on its flight parameters more than a visual one does. Flying too fast costs thermal resolution, and a varying altitude means your frames no longer line up with each other — so keep the speed low and constant, and the altitude constant.

But the point that reaches beyond UgCS: the radiometry sits inside the original R-JPEG files, per pixel. A thermal mosaic built afterwards looks like temperature, but no longer is. When your client asks "how hot is that connector", the answer comes from the originals. So plan the mission such that those originals stay usable, and deliver them alongside your processed product rather than instead of it. In DronePortal they stay behind the client login, with per-pixel temperature readable in the browser and no DJI software needed at your client's end — here is how that works.

Where UgCS stops — and what still has to happen

UgCS plans and flies. It reconstructs nothing and delivers nothing; SPH Engineering says as much itself and points to Metashape, Pix4D and comparable software for the processing. In full, the chain looks like this:

1. Plan — UgCS: area or façade, camera, GSD, overlap, altitude mode, terrain data. Save the route.
2. Fly — execute the mission, with the same parameters as last time.
3. Process — WebODM, Pix4D, DJI Terra, Metashape or whatever you use. Orthomosaic, 3D model, point cloud.
4. Deliver — one address for your client, with the viewer, the report, the original imagery and the parameters that belong with them. That is where DronePortal sits.

That last step is not a formality. You engineered accuracy in step 1 and built a reconstruction in step 3; if step 4 is a shared folder, the evidence for all of it exists nowhere. DronePortal processes nothing itself — it embeds the viewer you published elsewhere, holds your original imagery, and carries the text around it that appears in no export folder.

What to carry from the flight plan into the delivery

This is the heart of the page. The following facts live in UgCS after the mission and nowhere else; they cost you three lines of text and they change what your client is holding:

• GSD — the figure, and whether you set it or it followed from the altitude
• Altitude mode — AMSL, AGL, Smart AGL or rangefinder; without it the GSD figure floats free
• Camera and lens — and whether the profile was a stock one or custom-entered
• Overlap — forward and side
• Capture date and time — on thermal work the time of day is part of what you are seeing
• Route name or version — the only thing that ties a future flight to this one
• EPSG code, plus the RTK or PPK reference if you used one
• What the mission did not cover — the north façade, the strip behind the trees, the section under the crane

That last one is the hardest and the most valuable. A deliverable that names its own gaps reads as craftsmanship; one where the client has to find them reads as a mistake.

In practice: the actual clicks

1. Publish your viewer first. DronePortal hosts no tiles and no 3D viewer of its own; it embeds the URL you paste. So publish your model or map to Sketchfab, a map viewer or another embeddable environment first and copy that page URL. Pasting the ordinary page URL is enough — DronePortal converts Sketchfab, Matterport and Kuula links to their embed form on save. Only skfb.ly short links are refused, with a message.
2. Dashboard → "+ New project". Pick an existing client or type the name and e-mail straight into the form. Name the project, give it a type, name the first unit. On save, DronePortal creates the client, the project and the unit, generates an 8-character access code and drops you into that unit's edit screen.
3. Section 🗺 Viewers. One row per viewer: the type (3D Visual, 3D Thermal, 2D Map, 360° Tour), a label your client will read, and the URL. Below it you pick the Main viewer — the one that opens first — or leave "Automatic (first viewer)".
4. Section 📋 Documents & media — this is where your flight parameters land. "+ Add document or link", set the type to File, and upload your report or findings PDF. This is the place for the list above: GSD, altitude mode, camera, overlap, route name, EPSG. Put them in the report or in the label, but put them somewhere. The NL/FR/EN label fields are the button text your client sees.
5. Section 📷 Photos — the originals, not a flattened copy. Thermal, visual and zoom. On a thermal mission this is the difference between deliverable temperature and a coloured picture. Upload a selection, not the entire map.
6. Section Portal — open it up. Status to Active, pick the language, fill in the capture date (on a monitoring series this is the field that makes the series readable) and an expiry date if the job calls for one. The access code is in that same section.
7. Next flight: new unit, same project. Same route in UgCS, new capture date in DronePortal. That way the series grows inside one portal instead of inside your mailbox.

Open the client link yourself in a private window before you send it. That is the only way to see what your client sees rather than what your own logged-in session shows.

Four ways a well-planned mission still goes wrong

1. The GSD appears nowhere in the delivery. You calculated it, set it and flew it, and your client does not know it. Then your map is a picture.
2. The second flight uses a new route. Redrawn, slightly different — and the comparison with last year has quietly become worthless.
3. A custom camera profile with the 35 mm equivalent. Every derived figure is wrong, and nothing in the software warns you.
4. The thermal mosaic replaces the originals. The result looks better and can do less. The radiometry is gone.

Next in the chain: delivering a WebODM project · delivering a Pix4D project · delivering a DJI Terra project. Further reading: delivering radiometric thermal images and six links for one inspection.

Frequently asked questions

UgCS is a product of SPH Engineering. We are not affiliated with SPH Engineering; this page describes how a mission planned in UgCS ends up inside a DronePortal delivery.

Ready to start?

Deliver your next mission the way you planned it

Try DronePortal free — no credit card required.