Your Data Is Worthless Until It Becomes a Deliverable

Nothing bothers Rami Tamimi more than watching someone spend hours building a beautiful dataset that never actually gets used. "There needs to be purpose for your data," he told the ROAR West crowd. "Data alone is useless." (watch at 0:00) It's a blunt way to open a session, but it sets up the entire workshop. A point cloud, no matter how dense or how carefully it was collected, is not a deliverable. It's raw material. The deliverable is whatever your client can actually act on: a survey plan, a site plan, a boundary, a drawing the city will accept.

"They're going to say, cool point cloud. Where's my drawing? Where's my site plan? Where's my boundary?" Tamimi said, describing the moment a client receives a dataset instead of an answer. "Engineers want to design off of your work. They're not going to design off a point cloud. They're going to design off a survey plan. Regulators are not going to approve the point cloud. They're going to approve your survey plan. And crews build off of construction plans." (watch at 0:44)

2D is against my religion — except when someone has to pay for it

Tamimi brought up a friend in the reality capture world, Michael Gula, whose slogan is "2D is against my religion." It's a fair rallying cry for people who love collecting 3D data. But Tamimi pushed back on it directly: "Your 3D data is meaningless until it becomes 2D data that someone can actually pay for." (watch at 1:26)

There's a real market for 3D deliverables like digital twins, and Tamimi isn't dismissing that. His point is narrower: in most survey and mapping work, the value isn't the 3D dataset itself, it's the information that comes out of it. An inspection report generated from a drone flight is a 2D PDF. A topographic survey generated from a point cloud is a 2D drawing. "The real value comes with the information that comes out of those data sets." (watch at 2:04)

Figure out the deliverable before you ever fly

The practical consequence of this is a sequencing problem a lot of mapping providers get backwards. It's tempting to fly first and figure out what to do with the data later. Tamimi's approach is the opposite: talk to the client, figure out what the project is actually for, and only then decide how to collect the data.

He gave a simple example. If a client wants to put in a swimming pool, you need full 3D grading data. If they want to put in a fence, you probably don't need a drone flight and a point cloud at all — they just need the property lines. "Why would I go fly a drone and create a point cloud when all he's asking for is this property line?" (watch at 2:45)

Before collecting anything, Tamimi runs through a short list of questions:

• What is the project for? A one-off stockpile estimate needs far less control and rigor than a legal boundary survey.

• Who's going to use it? An engineer needs CAD deliverables. A judge needs a legally defensible survey plan. Knowing the audience determines the format. (watch at 3:23)

• What accuracy does it actually need to meet? A legal boundary survey might need to meet the "one part in 5,000" standard covered in Part 2. A general water-flow study doesn't need the same rigor around control.

• What's the deadline? A one-week turnaround changes how you plan data collection and processing versus a two-month window.

• Does this need a professional to sign it? This is the question Tamimi says he comes back to the most: "Are you defining property lines? Are you doing something that is... now considered professional work, or are you doing general mapping work at a higher accuracy? Figure out where that line is." (watch at 4:02)

He's also direct about the technical groundwork that should happen before a single flight: confirm the coordinate system, the datum, whether the client needs grid or ground, and the accuracy expectation. "Sometimes your client won't know the answer. It's your job to educate them." (watch at 5:11)

The takeaway

A dataset isn't worth anything until someone can use it to make a decision, sign a document, or build something. The questions above take ten minutes with a client and save days of rework later — redoing a deliverable in the wrong format, discovering mid-project that a license was required, or handing over a point cloud to someone who needed a survey plan.

At Remote Robotic, every mapping and LiDAR project starts with exactly this conversation: what's the deliverable, who's going to use it, and what accuracy actually matters for that use case. That's how a flight turns into a drawing someone can build from, not just a file that sits on a server.

Survey & mapping solutions · DJI drones for survey & mapping in Canada