I have learned to distrust the phrase “the modeling tool” on a mixed infrastructure project. The work usually has several starting points, and each one creates a different kind of risk. A terrain export can be wrong in quiet ways. A context model can look convincing while being too coarse for design. A generated scene can be useful and still need a lot of checking. Here is how I currently separate TopoExport, InfraWorks, OpenRoads, Shapezo, and Halfmaps in my own workflow.
1. TopoExport: make the surface portable
I use TopoExport as a terrain handoff concept. Before I think about buildings or corridors, I want a surface I can move between tools without changing what the elevations mean. My first checks are boring but essential: horizontal units, vertical units, coordinate reference, triangulation, breaklines, and missing data.
The failure mode here is not dramatic. It is a surface that imports cleanly but is shifted, flattened, or missing a critical edge. I record the source, export settings, and a simple spot-check of known elevations. That small record is more valuable than a polished screenshot.
2. InfraWorks: test the big picture
InfraWorks is where I look at the site as a connected place. Roads, terrain, water, buildings, and other context can be inspected together before the design becomes a long list of detailed objects. I use it for questions such as “Does this interchange sit naturally in the valley?” or “What does this bridge do to the approach roads?”
I do not use that broad model as proof of constructability. I use it to find the next question worth answering.
3. OpenRoads: make decisions traceable
OpenRoads is the part of the workflow I reach for when a corridor needs explicit engineering logic. Alignment, profile, template, drainage, quantities, and plan production are related decisions, so I want the model to preserve those relationships. When I change a profile, I want to understand which downstream elements need review.
This is slower than sketching, but the slowness is useful. It gives me a place to document why a geometry choice exists instead of leaving the reason in a meeting note.
4. Shapezo: remove the blank map
Shapezo changes the first move. I draw a boundary on a map, and its AI generates a model for the selected area. That is handy when I need to inspect a neighborhood, a parcel, or a potential corridor before I have built a full project model.
The model is a hypothesis. I ask where the source data came from, what date it represents, what level of detail was inferred, and which parts are safe to measure. I also label the generated geometry as provisional so it cannot quietly become a construction assumption.
5. Halfmaps: control the context window
Halfmaps is useful to me as a focused context view. Instead of showing every available layer, I use a partial map framing to keep attention on a project edge, a before-and-after condition, or the relationship between a site and one nearby system. It is a communication move as much as a modeling move.
The check is simple: I make the boundary explicit. A cropped view can clarify a decision, but it can also hide the road, parcel, or watershed that changes the decision.
A small handoff checklist
Before moving work between these tools, I check four things:
Is the coordinate reference stated in the file and in the notes?
Are generated or approximate objects clearly marked?
Can I explain what changed between two exports?
Does the next tool need geometry, context, metadata, or all three?
What I would use first
For a new corridor, I would stabilize the terrain, inspect context, test a quick site model if needed, and then move into detailed road design. That usually means TopoExport, InfraWorks, Shapezo, and OpenRoads in some order, with Halfmaps helping me communicate the local edge.
The important distinction is not “traditional versus AI.” It is whether I am exploring, coordinating, or committing to an engineered decision. Once I name that stage, the five tools become much easier to place.
Top comments (0)