You fly the mission, upload the images, and a few hours later you are staring at a processing report with two separate output options: an orthomosaic or a point cloud. Sometimes, the client didn't even state which one they wanted out of the two. Half the time they required that we give them "3D data" when a flat map (one measure of that information) would have taken 1/3 of the processing.
This kind of misunderstanding is one of the most common — and costly — errors in perhaps drone surveying. Not necessarily because both outputs are computationally intensive to produce, but instead subsumed by the fact that ordering the wrong one typically means reprocessing, re-flying, or handing a client something they don't really know how to use. Before you burn a flight on it, here's how to tell which one your project really needs.
What an Orthomosaic Actually Is
An orthomosaic is a large aerial photo created from hundreds (and usually thousands) of smaller overlapping photos taken with a drone. It's orthorectified — meaning unlike a raw, unrectified aerial photo, corrected for lens distortion and detail. That is a big part of why it is something you can measure: you pull distances and areas and boundaries right off the image, and they hold.
Orthomosaics are usually delivered as GeoTIFF files that drop right into GIS platforms like ArcGIS or QGIS. Resolution is typically specified as ground sample distance (GSD) — the actual size of a single pixel in the real world, 1–3 cm/pixel for a typical mapping mission. A lower GSD means more detail, but it means lower altitude and more images – so it's not free; that's a trade-off you define at the flight-planning stage (not something that you correct during processing).
Weaknesses of orthomosaics: they're flat. They depict how the area of the site would appear when viewed from directly above them, but they do not contain elevation data in and of themselves. If somebody gives you an orthomosaic and says, "Can I get a cut-and-fill volume off of that?" That is not something the file can tell you — that confusion is exactly the type of mismatch this post discusses.
What is a Point Cloud Made Of?
A point cloud is a 3D dataset — millions of individual points, each having an X, Y, and Z coordinate to determine the physical shape of the scanned area. Depending on how it was captured, this may carry either RGB values (from photogrammetric processing) or classified by return type—ground, vegetation, building (typical of LiDAR captures).
In this case, it is important to get right the difference between each of the 2 capture methods above. This creates photogrammetric point clouds, which you can think of as the same overlapping images to create an orthomosaic — again run through structure-from-motion processing (no extra sensor needed) but just representing what was seen by the camera (dense vegetation or overhanging areas will cause gaps). LiDAR uses a laser sensor, able to penetrate canopy gaps and return ground points below at the price of requiring a specialised (and pricier) payload. Photogrammetric density is normally around 50–500 points/m2; LiDAR often runs 100–500+, with tighter vertical accuracy in vegetated terrain.
LAS or LAZ are formats for the point clouds and require specialized software — CloudCompare, Global Mapper, CAD solutions like Civil 3D etc. That is a true cost consideration: if the client's team doesn't have a point cloud viewer and only has GIS software, giving them a .laz file does them no good no matter how accurate.
The second output also communicates accuracy differently, and it is important to know not to mix them in a conversation with your client. Orthomosaic accuracy is measured as root mean square error (RMSE) against ground check points — a single horizontal metric. Point cloud accuracy, which is independent of horizontal RMSE as it describes point density + vertical error. A common dilemma is: If a client asks "how accurate is this" the answer to that question really depends which deliverable, and on what axis.
Orthomosaic versus Point Cloud – What Do You Really Need?
The honest truth: it completely depends on what the deliverable is meant to inform.
If your project requires some 2D measurement — area calculations, checking whether things are in the right spot, showing progress over time, a reference frame that a non-technical stakeholder can recognize without special training — reach for an orthomosaic. An orthomosaic is useful for a project manager because they see an image of what's happening on site immediately, which is not the same case with a raw point cloud as it reads like an abstract cloud of dots — someone must process that data and classify it.
Grab a Point Cloud when it is 3D geometry that the project calls for — volumetrics, terrain modeling, earthwork quantities or anything going into a CAD/BIM workflow. A point cloud acts as a geometric anchor: it is the raw data engineers build digital surface model (DSM) and a digital terrain model (DTM) from — here the distinction is important since a DSM will make you see the top of all things (building, tree, equipment), however in a DTM, that have been stripped away so only bare-earth elevation remains. Mixing the two will get you quickly discredited in front of an engineering client.
If you are only budgeting for one, what decision the deliverable is truly informing? 'Show the progress of a client site' refers an orthomosaic. Point cloud (and maybe DTM / DSM comparison on top) —> Calculate stockpile volume
Can One Drone Flight Give Both Results?
That is to say: yes — and this is something that can be important to know about before you decide that you need to choose. Both results derive from the same true photogrammetric process, running through a render of dense point cloud lensing to finally rendering the aligned-orthomosaic. If the front and side overlap values are sufficient (60% forward / 30% sidelap minimum for basic mapping, higher for precision work), one flight can create both deliverables without needing to return to the site. Processing time, not flight time is the additional expense — which is precisely why it is advisable to clarify the entire list of deliverables with the client before, not after a mission.
What they all have in common: Industry Examples — Same Site, Different Deliverable
Construction: An earthwork superintendent often needs both: An orthomosaic for the weekly progress photo that goes into client presentation and a point cloud (or the DSM/DTM resulting from it) to create the actual cut-and-fill volumetric report which integrates with that project's Civil 3D model.
Agriculture: NDVI and crop health mapping runs almost entirely on orthomosaic-style outputs (multispectral Imagery mapped to a georeferenced 2-dimensional surface). Unless canopy height is at the heart of your analysis, a point cloud will do little to add value here.
Land development: surveys, Topographic surveys are the basis for site planning with DTMs and contour maps derived from a point cloud … typically the deliverable that goes into grading design not the orthomosaic imagery layered on top.
In a recently completed corridor survey of tail race infrastructure for a hydropower survey, we reduced 837 images into a 54.6-million-point dense cloud and aligned with an orthomosaic at 5 cm/pixel, both from the same flight and referenced to 18 ground control markers in the area. The client used the orthomosaic for stakeholder visualization, and it also includes the point cloud to put into their actual terrain modeling. Neither would have paid the wages for both positions by itself.
What are the financial implications of picking an incorrect deliverable?
More than most pilots expect. Should a client realize that they want volumetric data halfway through a project, and they're only left with an orthomosaic, the shortcut is not exporting — it's a re-flight (or at least redeveloping the original imagery to create a dense point cloud if there is enough overlap and if the raw images support it). That's schedule time lost on top of losing the time it takes to rework.
This more costly version of the mistake takes place without warning: a group decides earthwork quantities, grading plans based upon a deliverable that was never intended to help with that threshold of accuracy and the error just simply does not occur until something in the field is incompatible. This is cheapest insured against with a structured deliverable-acceptance conversation before the flight, not after. It costs a five-minute call. And the same rationale that makes warrant extracting and validating file formats — like GeoTIFF, LAS/LAZ, DXF — so that files never arrive at a workflow where they cannot be properly used.
Right First Time
Orthomosaics and point clouds are not competing outputs — they're different tools created from the same flight, and in fact most projects require some combination of both depending on the stakeholder. The problem is not that you are choosing the wrong one but that you do not ask upfront. Before your next mission, know what decision the deliverable needs to support and verify that with what format the recipient team can open.
If you get that conversation right before mobilizing, we completely skip the reprocessing calls. If you're interested in a second set of eyes on a deliverable plan before you fly — or want to see how a mixed orthomosaic/point cloud deliverable set works out over an actual project, here is some recent work.
