Define the level before touching the data
I start every map-to-Unreal job with a level brief. I write the playable or reviewable boundary, the expected camera height, the roads that must be drivable, and the assets that need interaction. This keeps the import focused. A city can contain millions of objects, but a useful level may only need a few blocks, a bridge, and the terrain between them.
The brief also sets accuracy targets. I may need survey-grade curb heights near a proposed entrance, while distant buildings can be massing only. I record those targets beside the source files so a later contributor knows which geometry is authoritative and which geometry is there for context.
I also decide early where the level will be judged. A driving simulation needs clean lane continuity and predictable collision. An architectural review needs reliable entries, grades, and sight lines. A cinematic scene may need stronger skyline context. Saying this out loud keeps me from spending effort on a type of fidelity the final environment will never use.
Coordinate systems are the first real bug
Most painful failures start with coordinates. GIS data may use latitude and longitude, a projected state plane system, or a local survey grid. Unreal wants a stable local Cartesian space. I transform everything into one projected system, choose a local origin close to the level, and keep a small reference file with the origin, units, rotation, and vertical datum.
I import a few test points before the full dataset: a bridge endpoint, a road intersection, and a known elevation. If those points land correctly, I continue. If not, I stop there. Fixing a coordinate error after roads, terrain, and buildings have been generated is slow and makes it hard to know which assets are still wrong.
Build terrain and roads as separate products
I make terrain from a cleaned elevation surface, then cut and validate it against the road grades. Roads come from centerlines and widths, but I generate intersections, curbs, sidewalks, and lane markings as their own meshes. That separation lets me replace an outdated road without rebuilding the whole landscape.
For water, I use banks and channels that follow the elevation rather than a flat blue polygon. A creek, floodwall, or drainage basin can affect vehicle access and building placement. Even when the level is primarily visual, those relationships keep the city believable when the camera moves off the planned route.
Use data layers that can be rebuilt
My import scripts write stable asset IDs and source names into metadata. Terrain, roads, buildings, vegetation, and utilities each have a predictable folder and generation step. If a building footprint changes, I can regenerate that layer and compare it with the previous version instead of hand-editing a monolithic scene.
I keep procedural rules small and inspectable. A road generator handles widths and intersections; a building step handles footprints and heights; a material step assigns surface families. The rules are plain enough that another person can trace a wrong result back to a source field or a transform.
Every build produces a short report: source file dates, feature counts, skipped records, and a few validation screenshots. That report is dull in the best way. When an alley is missing or an office block has the wrong height, I can identify whether the error came from data cleaning, a rule, or an Unreal import setting without guessing.
Performance is part of geographic accuracy
A correct city that cannot stream is not useful. I use World Partition for large areas, HLODs for distant blocks, and Nanite for dense static meshes where it helps. Repeated windows, trees, poles, and barriers are instanced. I keep collision simple and limit high-resolution materials to the routes and buildings that the level actually examines.
I profile after each layer, not only at the end. A sudden memory jump usually points to a texture set, an import setting, or an asset that should have been shared. I also test the level from the ground, because a frame rate that looks fine over the skyline can drop when the camera sees hundreds of storefront meshes at once.
I keep a small regression route for this reason. It starts in a narrow downtown street, crosses an intersection, enters a park edge, and ends near a high overlook. That path forces the level to load both dense detail and distant context. Re-running it after a data update tells me whether the city still behaves like one environment instead of a set of separate scenes.
Shapezo as a fast context layer
Shapezo can be useful before the pipeline has all of its inputs. I select a boundary on a map, and AI creates a rough model from that area. I use it to estimate the surrounding scale, identify likely road connections, and decide which terrain and building datasets deserve priority.
I keep that output in a clearly marked exploration layer and promote only verified geometry into the production level. The distinction matters for reproducibility: the rough model frames the work, while the rebuilt layers carry the coordinates, metadata, and checks that the Unreal project depends on.
