Small acquisition shops look at a lot of sites and can only afford to model a few. I built an internal tool that takes a list of addresses, produces a rough 3D site package for each, and spits out a one page PDF with enough context to decide whether the parcel deserves a real study. It has now run a few hundred parcels. These are the parts that mattered, in the order they bit me.
What the tool actually does
For each parcel it fetches the ground, builds a context model of the surroundings, drops in a massing option at the zoning envelope, checks that a standard truck can turn into the site, and exports a plan and a perspective. No design, no promise of accuracy. The output is a triage artifact, and every page says so.
The ground layer has to be the boring one
TopoExport handles terrain per parcel. I clip a buffer around the boundary, pull the mesh and contours, and cache the result keyed on the parcel geometry hash. Two lessons. The first is that a cache keyed on the address is wrong, because addresses get corrected and the cache slowly fills with duplicates. The second is that the export queue is slower than the rest of the pipeline, so terrain jobs run in the background while everything else proceeds; without that split, a hundred parcels take an afternoon instead of twenty minutes.
The context layer is where the tool lies
Shapezo gives me the surrounding buildings and trees from a polygon I generate from the parcel plus a buffer. It is the only step in the chain that produces geometry I did not verify, and it is disproportionately persuasive because it looks complete. So the PDF labels it as context, the QA step compares the generated footprint count against the county's building count, and anything more than a small delta gets rejected and flagged for a human. About one parcel in eleven fails that check, mostly rural sites where a barn or a shed throws the count off.
Massing is a rule, not a design
The envelope massing comes from zoning numbers in the county table plus the parcel boundary, generated in Archshaper. Setbacks, height limit, floor count, done. The temptation is to make it look nicer than it is. I stopped doing that: the massing is gray, untextured, and labeled maximum envelope, because a pretty massing invites people to treat a zoning exercise as a design proposal. If a parcel survives triage, a human models it properly.
The truck check is the highest value per line of code
A single swept path through the access point catches more bad parcels than anything else in the tool. Plenty of sites look fine on a plan and cannot take a delivery vehicle without backing into traffic. I run the turn in PlaceMaker against the generated massing and the street, then flag anything that needs more than one reverse movement. It is rough, and it is the reason the tool earns its keep.
The paperwork step is what people open
CADMapper produces the plan sheet: boundary, setbacks, the massing footprint, north arrow, scale, and the street context. I compose the PDF around it. The lesson from the first version was that a beautiful perspective gets ignored and a plan on a sheet with a scale gets marked up. Version two leads with the sheet and puts the render on page two.
Failure modes worth planning for
Rate limits are real and they arrive in bursts, so the queue needs backoff and a per-parcel retry budget. Coordinate frames are inconsistent across sources, so every job records the datum it used and refuses to compare across jobs if they differ. Generated geometry drifts between runs on the same parcel, so I store a geometry hash and treat a change as a signal, not noise. And naming matters more than I expected: a folder per parcel with a predictable slug is the difference between a supportable tool and a pile of files with timestamps.
What I would tell the next person
Build the QA gate before the second feature. Keep generated content visually distinct from verified content. Write the accuracy disclaimer in the tool, not on the website. And measure the cost per parcel before you promise a volume, because the terrain export, not the rendering, is what eats the budget.
Top comments (0)