Five Checks Before You Import an AI Site Model into OpenRoads

Last month a colleague dropped a folder on our server with a GenAnywhere export and a note that said site context, ready to use. I opened the mesh, looked at it for a minute, and did not touch it again for three days. Not because it was bad. Because I had not checked it yet.

This is the list I run before any AI-generated site model goes into an OpenRoads file. It takes about an hour. It has caught a wrong vertical datum twice this year and a units problem once.

Start with the file format and the coordinate system. The viewer does not care where the model sits. OpenRoads does. Ask which coordinate system the export uses, and whether the numbers are feet or meters. A model in state plane feet imported as meters will look plausible and be wrong by a factor of 3.28.

Measure a road width you can see on imagery. A two-lane road with shoulders is roughly 30 to 40 feet. If the model says 120, you have a units problem, not a wide road. If the file arrives as LandXML, open the header before you open the surface.

AI models often sit on a smooth global terrain, and the elevation may be relative, ellipsoidal, or simply offset. Check the minimum and maximum against a benchmark you trust. A site at 620 feet NAVD88 should not import at 1,840.

Pick a spot with a known elevation, usually a manhole rim or a surveyed benchmark. Compare. If the difference is constant, you can shift the model. If it changes across the site, the surface is not usable for design.

A mesh is not a TIN surface. It has triangles, but it does not know which edges matter. Walls, curbs, ditch bottoms, and top of bank are all inferred. Sometimes the inference is fine. Sometimes it cuts a corner through a retaining wall and nobody notices until the cross sections look strange. OpenRoads wants a breakline wherever the ground changes direction sharply, and the generated model rarely has one.

Turn on triangle edges and look for long skinny triangles crossing a road or a wall. Those are the places the surface is guessing. On a bridge job last winter, the mesh ran a single triangle from the deck edge to the creek bed. The deck looked fine in 3D and the profile was wrong by two feet at the abutment.

Check scale with two points you can measure on the ground, not with the viewer zoom. If the model is off by one percent over a mile, that is 52 feet. GIS data is often close enough for context and not close enough for design. If the source was a point cloud, ask how it was decimated, because decimation can move a curb.

The list is short and expensive: utilities, walls, culverts, inlets, guardrail, and anything underground. On a warehouse project, the generated model had the building and the parking but not the dock heights. We design to the dock, so the model was context, not a base. The same thing happens with drainage. A low spot in a parking lot is easy to see in a render and easy to miss in a mesh.

I keep a small script that reads an exported point file and prints the elevation range and a count of impossible values. It is not validation. It is a smoke test that catches the obvious failures before they reach a design file. The automation is deliberately dumb, because dumb checks are easy to trust.

For a public meeting or a quick visual, I skip all of this. The model goes into a viewer, not a design file. The checks exist for the moment someone says ready to use. That phrase is the trigger. A quality check is cheaper than a redesign, and a file format note in the project log is cheaper still. If the model fails two checks, I stop and ask for the source. There is no point patching a surface that was never measured.