Point cloud classification is one of the most expensive and slowest tasks in any LiDAR project. Every year, what AI can automate improves — but so does the confusion about where the model ends and human judgment begins.
What AI does well today
For the majority classes — ground, vegetation, buildings — current models consistently achieve very high accuracy. In power line inspection projects, separating vegetation, towers and conductors is now a largely solved problem at millions of points per minute, even across corridors of dozens of kilometers with notable vegetation and terrain changes.
This is no coincidence: these classes have very consistent geometric patterns (ground planarity, structure verticality, vegetation dispersion) that current models capture well from thousands of previous training projects. The practical result is that a very high percentage of the corridor needs no human eye at all.
Where it still falls short
Difficulties appear at the edges: minority classes, ambiguous objects and low point-density areas. A model trained for one type of terrain performs worse on another, and false positives in critical classes (e.g. noise mistaken for a cable) carry a disproportionate cost, because a single misclassified point on a conductor can trigger a false vegetation-encroachment alarm.
Another common blind spot is transitions: the edge between a roof and the vegetation touching it, or where a pole meets the ground. There, geometry is ambiguous even to a trained human eye, so demanding a perfect boundary from the model is asking for something the data itself can’t resolve with certainty.
AI doesn’t replace the operator. It reorders their work: from mass labeling to reviewing what’s uncertain.
The human operator doesn’t disappear
The expert’s value shifts toward quality control: validating what the model flags with low confidence, fixing systematic errors and signing off the deliverable. That’s why error editing has to be integrated into the same environment as classification — not a separate tool that forces exporting, correcting and re-importing, losing context and time on every round trip.
This is exactly what Neobora integrates into a single environment: AI-based cloud classification and error editing coexist in the same tool, with high-productivity controls designed for quality control. The operator validates, corrects and signs off without leaving the platform or exporting the data to separate software.
In practice this changes the role’s profile: fewer hours of repetitive labeling and more hours of technical judgment applied to the cases that truly need it. Teams that make this transition well don’t cut staff, they redeploy it toward quality control, exception handling and client relations.
A realistic workflow
At Neobora the workflow is: automatic cloud classification → assisted review of low-confidence zones → targeted editing → geoportal publishing. The operator only touches the percentage of data that truly needs it, and the rest flows without friction.
Metrics that actually matter
A model’s overall accuracy is the metric most shown in demos and the one that says least about a project’s day-to-day. Two indicators are more useful for deciding: the percentage of the corridor flagged for "review" after automatic classification, and the average correction time per kilometer once it reaches the operator.
A model that reduces the review zone to 3-5% of the total, with agile editing on that percentage, produces better delivery times than a model with slightly higher overall accuracy that requires reviewing 20% of the corridor in a scattered, unpredictable way.
How to evaluate a provider
Before committing to a classification platform, it makes sense to ask for three concrete things: a test on your own data (not the provider’s demo dataset), visibility into what percentage of the data gets flagged as uncertain, and access to correct those cases within the same environment without depending on a support ticket.
If a provider can’t show those three things with real client data, the accuracy figure in their sales pitch is worth little: it’s measured under conditions that rarely match the terrain, flight density or infrastructure type of your specific project.
At Neobora we start from precisely those three requirements: testing on the client's real data, visibility of the percentage of data flagged as doubtful, and correction within the same environment, with no tickets or external tools. We prefer to be evaluated with the project's own terrain in front of us, not with a demonstration dataset.
Conclusion
Expecting total automation from AI is a recipe for disappointment. Expecting it to multiply your team’s productivity — with the human in the loop where it matters, measuring what truly predicts delivery time — is realistic today. That’s Neobora’s bet.
