Why Your DXF Imports into Civil 3D with the Wrong Coordinate System

You open a DXF in Civil 3D, and the import dialog shows a coordinate system you didn't pick. Or you accept whatever it offers, and the drawing lands a few thousand feet from where it should — or in roughly the right place, but the distances don't quite check against your survey.

Nearly always, this is a units problem in the coordinate system definition, not a problem with the geometry.

NAD83 State Plane comes in two unit systems

Every State Plane zone has a metric definition and a foot definition. They describe the same projection with the same origin. Only the linear unit differs.

EPSG	Definition	Unit
EPSG:2272	NAD83 / Pennsylvania South	US survey feet
EPSG:32129	NAD83 / Pennsylvania South	meters

If your drawing is tagged with the metric code but your CAD file is drawn in feet, everything is off by a factor of 3.28. That one is easy to spot — the site is obviously in the wrong place, or obviously the wrong size.

The harder one: US survey feet vs international feet

There is a second, quieter split inside the foot definitions.

The US survey foot is defined as 1200/3937 meters. The international foot is defined as 0.3048 meters exactly. The difference is two parts per million — about 0.01 feet across 5,000 feet.

That is small enough to pass a visual check and large enough to matter when you're tying into survey control or a state plane monument.

These states aren't an EPSG error — they legislated the international foot. The problem is a pipeline that assumes US survey feet everywhere, which is wrong in six states out of fifty.

Utah is the one to watch, because it publishes both. The international-foot codes (2280–2282) are the ones that look canonical, so a pipeline reaching for the obvious code gets international feet; the US survey foot versions sit further out at 3560, 3566 and 3567. Utah is the only state where EPSG gives you the choice at all — for the other six there is no US survey foot code to pick.

How to tell which one you got

Civil 3D reads the coordinate system out of the DXF's GEODATA block and shows it in the import dialog. You don't have to guess.

What's stored in that block is an ESRI-flavored WKT definition, and its name carries the unit:

• NAD_1983_StatePlane_Pennsylvania_South_FIPS_3702_Feet — US survey feet
• NAD_1983_StatePlane_South_Carolina_FIPS_3900_Feet_Intl — international feet
• NAD_1983_StatePlane_Pennsylvania_South_FIPS_3702 — meters

The suffix is the whole story: _Feet is the US survey foot, _Feet_Intl is the international foot, and no suffix at all means meters. Utah's two variants sit right next to each other under this convention — the US survey foot zone ends _Utah_Central_FIPS_4302_Feet, the international one _Utah_North_FIPS_4301_Feet_Intl.

Civil 3D matches that definition against its own coordinate system library and displays its catalog code for the zone — for Pennsylvania South, PA83-SF for feet and PA83-S for meters. If you expected feet and the dialog says PA83-S, stop there — importing it will not fix itself downstream.

Checking a file before you import it

If you want to look before opening it in CAD, the GEODATA section is plain text inside the DXF. Search for StatePlane and you'll find the definition Civil 3D is about to match against, including the _Feet / _Feet_Intl ending that tells you the unit. The trailing UNIT[...] clause spells it out too: UNIT["US survey foot",0.304800609601219] against UNIT["foot",0.3048].

With GDAL installed, gdalsrsinfo on the file will report the CRS, including the linear unit, without opening anything.

Either way, the check takes ten seconds and saves you from finding out after you've already started drawing against it.

What this looks like in practice

Most of the time this shows up as a file someone downloaded from a state or county portal, pulled into CAD, and assumed was in the units their drawing was already using. The data isn't wrong. The units declaration just doesn't match what the file is actually drawn in, and nothing in the workflow forces the two to agree.

basemappr resolves the State Plane zone for your extent automatically and writes the correct foot definition for that state into the GEODATA block, so what Civil 3D reports in the import dialog is what the geometry actually is.