If you’ve ever hard-coded a threshold in firmware, you know how this goes. It works on the bench. Then a sensor drifts, or the environment changes, and the clean rule meets a messy world. Detecting objects in 3D scan data has the same problem at a much bigger scale.
The fixed-rule approach
Say you want software to find poles in a point cloud. A rule-based method describes a pole in geometry: taller than a few metres, narrow, close to vertical, standing on the ground. That’s quick to write and easy to explain. Rules have a real advantage: you can read them and see exactly why a point was labelled a pole.
And it breaks. Tree trunks are tall, narrow and vertical. So are downpipes, sign posts and the legs of a bus shelter. You add exceptions, the exceptions interact, and the rule set turns into something nobody wants to touch.
The trained-model approach
A trained model flips the work. Instead of writing the description, you supply examples: scans where a person has already marked each lamp post, drain and manhole. The model works out which geometric characteristics separate one class from the others, then applies that to new point clouds.
VisionSpot’s point-cloud detection follows this pattern for surveying. Its sequence has four steps: labelled training examples, learned characteristics, application to new data, and structured output. Detected features arrive as topographic data a drafter can use. The payoff is that the model can improve as examples are added, without anyone rewriting the logic.
A small illustration
Take the pole versus tree trunk problem again. Show a model many labelled examples of both and it can pick up differences a hand-written rule would never include: how the cross-section changes with height, whether anything branches off above, how regular the surface is. Nobody had to list those differences. They came out of the examples.
What a trained model costs you
Nothing here is free. Someone has to label the examples, and the labels set a ceiling on quality. A model trained on one kind of scene can stumble on another: a different scanner, a different city, objects that look slightly different. Adding a new class means another round of training. VisionSpot’s own page describes its feature classes as trainable and expandable to a team’s own library, which is the right design for that reason.
Why both approaches still need a check
Neither method knows when it’s wrong. A rule fails loudly, in the cases you can predict. A model fails quietly, in the cases you can’t. So the workflow matters as much as the algorithm. In VisionSpot you run detection, read the list and choose which objects go forward before anything is processed.
What to take from it
If a vendor says “AI”, ask what changed between rules and training. Ask how the model is updated when it meets something new, too. A vendor with a clear answer has been through that cycle before. Then ask for a test. VisionSpot’s developers will process a sample file you send, calibrated to your drafting standards, free of charge. A good model should survive your messy data, and a good vendor should be glad to prove it.
