GIS-to-CAD Conversion for Utilities, Done Right
Why most GIS-to-CAD conversions lose the data that mattered, and how to keep it.
A good GIS-to-CAD conversion fixes the project coordinate system first, reprojects every source to it, and maps GIS attributes onto the CAD layer schema — so parcel IDs, asset types and ownership survive the conversion instead of being flattened to bare geometry.
Agree on one coordinate system first
Most conversion problems trace back to mismatched datums. Before any data is moved, the project coordinate system is fixed, and every source — parcel fabric, survey, GIS export — is reprojected to it. Everything downstream inherits that one decision.
Skip this step and features drift by metres, which is invisible on screen but fatal to a construction drawing.
The reprojection decision also has to be recorded, not just made. The source coordinate system of every input, the target the project uses, and the transformation applied between them belong in the project record — because a conversion nobody can reproduce is a conversion nobody can trust. When a discrepancy surfaces later, that record is what lets you find whether the fault was in the source data or in the move.
Preserve attributes, don't flatten them
Exporting GIS geometry to DWG and stopping there throws away the data that made the GIS useful. The attributes — parcel identifiers, asset types, ownership, phase — should be mapped into the CAD layer schema so they remain queryable in the drawing.
- Map GIS attributes to the client's CAD layer standard
- Keep parcel and asset identifiers intact
- Reconcile overlaps and gaps before drafting, not after
- Validate feature counts against the source
Make it repeatable
Conversions recur, so they should be built once and rerun. A tool such as FME lets you encode the reprojection, attribute mapping and QA as a workspace, so the next dataset runs the same way rather than being hand-converted from scratch.
Repeatability is also what makes the QA defensible — the same checks run every time, and discrepancies show up immediately.
Landbase is where it lands
For distribution design, the converted data feeds the landbase — the survey-true base every sheet sits on. Right-of-way and easements belong in that base, so corridor and design work starts from an accurate legal and physical footprint rather than a rough sketch.
The pitfalls that cause silent errors
The dangerous conversion errors are the ones that look fine. Geometry lands on screen, the drawing opens, and nobody notices that something is subtly wrong until a crew is standing in the wrong place.
Three recur often enough to check for by default. A datum or unit mismatch shifts everything by a consistent offset that's invisible without a control point to check against. Curved features exported as straight-line approximations lose accuracy on road alignments and easements. And multi-part or overlapping features collapse into single geometries, quietly dropping assets from the count.
None of these announce themselves, so the defence is a QA step that runs regardless of whether anything looks wrong. Checking against a known survey point, reconciling feature counts, and spot-checking curves and boundaries takes minutes and catches the offsets and dropped assets that would otherwise reach a crew.
- Validate against known survey control, not just visual overlay
- Confirm feature counts before and after conversion
- Check curve handling on roads, easements and boundaries
- Preserve, don't flatten, multi-part geometries
Common questions
- Can you convert both ArcGIS and QGIS data?
- Yes. Both are reconciled to the project coordinate system and mapped to your CAD layer schema; the source platform doesn't change the workflow.
- Will attributes survive the conversion?
- Yes, when the conversion maps them to the CAD layer standard rather than exporting geometry alone.
- How accurate is the result?
- As accurate as the sources once they're on a common datum — which is why fixing the coordinate system first is the critical step.