How to Get a Civil 3D TIN Surface from USGS Elevation Data

The problem

If you've done existing-conditions work for a site that doesn't have a topo survey yet, you know the drill for pulling USGS elevation data into Civil 3D:

1. Find the tiles you need on the National Map (3DEP 1/3 arc-second or 1-meter, depending on what's available for your county).
2. Download each tile — usually IMG or GeoTIFF, occasionally still LAS if you're going straight from point clouds.
3. Mosaic them if your site straddles a tile boundary.
4. Clip to your project extent in QGIS or ArcGIS Pro.
5. Generate contours or a raster-to-TIN conversion.
6. Export to a format Civil 3D will actually import cleanly — which usually means LandXML, because DEM-to-surface imports in Civil 3D are unreliable.
7. Import, discover your CRS didn't carry through, reassign it, and pray the Z-units match your drawing's X/Y units.

None of this is hard individually. It's just fifteen minutes of tool-switching for something that should be a five-second query. And you do it every time you scope a new site.

The shortcut

Draw a bounding box in basemappr around your project extent, select the elevation layer, choose LandXML with contours as the export format, and download. Import the LandXML into Civil 3D as a surface. Done — you have a TIN.

No tile hunting, no mosaicking, no separate CRS reassignment step. The export is scoped to your bbox and already in the right coordinate system and units for the drawing you're building.

Why it works: LandXML specifics

The reason this import is clean instead of "technically works but you spend twenty minutes fixing it" comes down to three things basemappr handles that most ad-hoc GDAL pipelines don't:

Z-units match X/Y. If your drawing is in US survey feet, the LandXML's <Units> element declares survey feet for both the horizontal and vertical axes. Civil 3D trusts whatever the file says — if elevation comes out in meters while your plan is in feet, it'll import at 1/3.28 scale and you won't necessarily notice until your surface looks flat. basemappr normalizes elevation to the same unit as your export CRS before writing the file.

Contours as a single-polyline IrregularLine, not a boundary mess. Civil 3D's TIN builder wants each contour written as one continuous <IrregularLine> under <Surface><Definition><Boundaries> or <Definition><Pnts>/<Faces>, depending on whether you're shipping breaklines or a full TIN definition. A lot of homegrown exports split contours at tile boundaries or write them as disconnected line segments, which forces you to manually stitch and clean before Civil 3D will triangulate sensibly. basemappr merges contour geometry across the whole bbox before export, so you get one clean polyline per elevation band.

State Plane CRS via county-epsg.json. basemappr resolves your bbox to the correct State Plane zone using a county-to-EPSG lookup table, then maps that to the matching Esri authority code for the LandXML <CoordinateSystem> block. Civil 3D reads Esri WKT more reliably than raw EPSG on LandXML import — this is the difference between "coordinate system: assigned correctly on import" and "coordinate system: unknown, please assign."

Here's what that surface definition looks like on the wire — one IrregularLine per contour, Esri WKT in the coordinate system block:

<Surface name="EG-Existing-Ground">
  <SourceData>
    <Boundaries>
      <Boundary>
        <IrregularLine>
          <PntList3D>
            1476523.12 543219.87 412.30
            1476540.55 543228.14 412.30
            1476561.02 543241.60 412.30
          </PntList3D>
        </IrregularLine>
      </Boundary>
    </Boundaries>
  </SourceData>
</Surface>
<CoordinateSystem name="NAD83 / Pennsylvania South (ftUS)" epsgCode="2272" />

Step-by-step

1. Open basemappr and shift+drag a bounding box over your site. Pad it a bit past your actual property line — you want triangulation to extend past your edge conditions, not stop exactly at them.

2. In the export panel, select the elevation/contour layer. Set your contour interval — 1' or 2' is typical for site design, 5' if you're doing a rough grading study over a larger parcel.

3. Name the file, submit, and wait for the job to finish. For a typical single-parcel bbox this takes well under a minute.

4. In Civil 3D: Insert → Import LandXML. Point it at the downloaded file. When prompted, add the surface definition — you'll see it under Surfaces in Prospector with contours already populated.

5. Check your CRS assignment (Toolspace → Settings → drawing properties) to confirm it landed on the right State Plane zone, then build your TIN and start pulling spot elevations or cut/fill against it.

Gotchas

Stray alignment objects. On some exports you'll see roughly 1,800 extraneous alignment objects come in alongside the surface — leftover artifacts from how the LandXML schema represents certain boundary conditions. They don't affect the TIN itself, but they clutter Prospector and are annoying to bulk-delete. This is a known issue and it's on the roadmap to fix at the export layer so the LandXML doesn't include them in the first place. Until then: select all in the Alignments collection, delete, move on.

NDVI-derived impervious surfaces are noisy. If you're also pulling an impervious surface layer for the same site, know that NDVI-threshold classification (green vs. not-green from recent imagery) is inherently noisier than a pre-classified source like NLCD or a state-level impervious dataset — shadows, wet pavement, and seasonal variation all shift the threshold. It's usable for a first-pass estimate but I wouldn't cite it in a stormwater narrative without a manual sanity check against aerial imagery. Pre-classified sources, where available for your county, are more defensible.