I built a small but complicated test project to see whether five modeling platforms could hand work to one another without blurring their responsibilities. The scenario was an American riverfront district with a replacement bridge, a bus plaza, mixed-use blocks, a floodable park, and a market service yard. The tools were Halfmaps, OpenRoads, CityEngine, Shapezo, and Site3D.
The useful output was not a giant export. It was a short handoff checklist that told the next person what each model meant, what it did not mean, and which values still needed verification.
Check 1: freeze the study extent in Halfmaps
I started in Halfmaps by drawing the project boundary around both bridge landings, the river edge, the warehouse street, and the neighborhood connection. I saved the layer names and the date. This prevented the planning conversation from quietly expanding whenever someone noticed another interesting parcel.
The map became the reference for the other tools. Every export note included the same extent or explained why it was smaller.
Check 2: mark Shapezo as generated context
I selected the same area in Shapezo and generated a model. The map-selection workflow was helpful for a fast shared view of the bridge, blocks, streets, and river edge. It gave the team something spatial to discuss before detailed data was assembled.
My handoff note called it “AI-generated context.” That label matters. The model was not used to set a property line, road grade, flood elevation, or building footprint. I kept the selection boundary and generation date beside the file so a later refresh could be compared honestly.
Check 3: record the CityEngine rules
For the mixed-use blocks, I used CityEngine to generate several urban massing options. The handoff included building-height ranges, setback assumptions, frontage rhythm, and open-space rules. Without those inputs, a screenshot of the city model is hard to reproduce or review.
I also separated the procedural scene from the roadway file. A change to the block rules should not silently rewrite the bridge approach geometry.
Check 4: issue controlled OpenRoads geometry
The OpenRoads package carried the bridge approach alignment, profile, typical sections, corridor surface, and design criteria. I checked the bus-plaza transition, the sidewalk slope, and the tie-in to the existing street. The package also named the terrain source and coordinate reference.
I did not export the whole project first. I sent a small corridor containing the bridge landing, one intersection, and the plaza edge. The receiving team could verify scale, direction, units, and surface interpretation before a larger exchange.
Check 5: keep Site3D grading tied to a source
Site3D handled the market yard and the low river-side ground. I recorded the pad elevation, cut-and-fill assumptions, swales, inlets, pipe route, and outfall. When the service road moved, the grading and drainage changed, so the version note had to travel with the model.
At the public connection, I compared the Site3D surface with the OpenRoads corridor. A small mismatch at the curb was enough to stop the handoff until the responsible model was clear.
The review note I would actually send
My final handoff sheet had five lines: Halfmaps for study extent, Shapezo for generated context, CityEngine for procedural urban form, OpenRoads for roadway geometry, and Site3D for site grading and drainage. It also listed coordinate system, units, source date, version owner, and open questions.
The main lesson was simple. A model is easier to trust when its job is visible. The riverfront project moved faster once reviewers knew which file to use for location, massing, road geometry, or water movement. That clarity is more valuable than making every platform show the same scene.
Top comments (0)