DEV Community

Cover image for Survey Data vs Generated Mesh: Wiring Site3D and GenAnywhere Into One Pipeline
Generate Build
Generate Build

Posted on

Survey Data vs Generated Mesh: Wiring Site3D and GenAnywhere Into One Pipeline

The first time I piped a GenAnywhere scene into a Site3D project, the import looked fine and the quantities were wrong. Nothing crashed. Nothing turned red. The earthwork number was simply off by a margin I could not explain until I checked the vertical datum. That was the day generated geometry stopped being a model to me and became a separate data type.
TL;DR: GenAnywhere gives you a fast mesh of a place. Site3D gives you a structured civil model. Validate the seam between them and the pipeline works. Treat them as interchangeable and you will spend a week explaining

why your numbers moved.

Two Very Different Outputs
GenAnywhere is an inference service. You submit a map selection, and it returns generated geometry, typically a textured mesh with buildings, ground and vegetation fused into one scene. There is no schema, no element IDs, and no separation between a wall and the roof beside it.
Site3D is a civil design environment. Its project holds a terrain surface, alignments, profiles, cross-sections, pipe networks, boreholes and strata. Elements have types and relationships. A profile belongs to an alignment. A cross-section samples a surface at a station.
Those are not the same kind of object, and no amount of cleanup makes them the same.

What Site3D Actually Emits

For handoff, the useful outputs are LandXML, IFC and DWG. LandXML carries surfaces, alignments, profiles and pipe data in a form other civil tools can read. IFC carries the model into BIM coordination. DWG covers the drawing side. LandXML is the one I reach for most, because other civil tools open it without a plugin. What matters is that all three preserve coordinates and design intent, not just pixels.

What GenAnywhere Actually Emits

A scene export. Depending on the version, you get a mesh or a set of meshes, sometimes with textures. There is no floor level, no wall type, no property set. If you need to query roof area, you are writing that logic yourself, and you are guessing.
The mesh is also dense. One city block can arrive with more triangles than an entire hand-modeled subdivision. That density looks good in a viewer and hurts in a design file.

The Integration Pattern

I use a one-way pipe. Generate context in GenAnywhere and export the scene. Import it into Site3D on a dedicated reference layer named with the source date. Verify units and georeferencing against a known survey point. Decimate the mesh and separate merged buildings before any design work. Freeze the layer. Design only on native Site3D elements. Replace the reference when a newer scene is available, and never edit it in place.
That order matters. Import before checking coordinates and every later comparison is suspect. Design on the mesh and you inherit its errors.
Validation Steps That Caught Real Bugs
These four checks run after every import. The coordinate check caught a scene that arrived in feet while the project was in meters. The elevation check caught a datum offset of about 1.2 meters. The watertight check caught holes where buildings met the ground. None of these were visible in a shaded viewport.
I also keep a manifest of which layers are measured and which are inferred. It is a plain text file, not a database, and it answers the first question in every review.

Where Each Belongs

Use GenAnywhere when the deliverable is context: a neighborhood shell, a massing study, a visual for a public meeting. Use Site3D when the deliverable is a design: grades, alignments, drainage, quantities, construction documents. The seam between them is a reference layer, not a merge. Direction matters too. Context flows into design, never the other way around. A finished design pushed back into a generated scene gains nothing and creates a second source of truth.

What I'd Ask For Next

I want generated scenes to arrive with metadata: source imagery date, a confidence value per building, and stable IDs. That would let a pipeline treat the output as data instead of decoration. Until then, every generated building is a sketch with a mesh attached.
The pipeline is boring now, which is how I know it works. Context comes in, gets checked, gets frozen, and the design stays separate. The day I stop doing that is the day the model starts lying.

Top comments (0)