Setting Up an Existing-Conditions Base in Civil 3D From ALTA Survey Data

An ALTA survey package arrives as a set of documents built for title insurance and legal review, not as a file ready to drop into Civil 3D. The sequence that follows only works if someone audits the package first and identifies what has to be extracted, converted, or requested separately before any import begins. A typical package includes a boundary or title drawing, often delivered as a PDF or a DWG, along with a legal description of the parcel. Some packages also include a georeferenced raster image or a digital CAD file. Point list or fieldbook exports, whether in CSV, TXT, or LandXML format, are not part of the standard ALTA deliverable set. Those files have to be negotiated with the surveyor as a separate request, and each format that comes back demands its own handling path once it reaches Civil 3D.

Point list formats are not standardized across survey equipment, so a CSV or TXT file might arrive as PNEZD (point, northing, easting, elevation, description), as PENZ, as ENZ, or in some other column order specific to the data collector that produced it. Figuring out which arrangement applies has to happen before import, not after. The most reliable path is asking the surveyor who generated the file directly. Where that is not possible, opening the file in a plain text editor and reading the column pattern against known elevation and coordinate ranges for the site usually settles the question, and testing candidate formats systematically against a handful of points is the fallback when neither of those gives a clean answer.

Coordinate system and units are the other variable that has to be nailed down before anything touches a drawing. Importing a point file under the wrong foot definition places every point slightly wrong without throwing an error, and that error compounds through every surface, alignment, and design file that references the data afterward. Skipping this audit stage is where rework begins: a format misread or a unit mismatch discovered three weeks into design costs far more to fix than catching it on day one would have.

Folder structure and file roles to establish before any data is imported

Once the package has been read and understood, the next decision is where everything is going to live. Existing-condition data needs a defined folder hierarchy, with the deliverable files sitting at the top level of the project's base folder and every source file pushed down into subfolders beneath it. That arrangement is what allows design and sheet files to reference the deliverables directly and pick up updates automatically, rather than requiring someone to manually redistribute changes every time a point gets corrected or a new survey pass comes in.

The base folder's top level contains four files that carry the weight of the entire existing-conditions base: Srfc-Ex.dwg for the existing ground surface, Srvy-Cntrl.dwg for construction survey control, Topo-Ex.dwg for topographic features, and Uti-Ex.dwg for utility features. The logic behind this split is straightforward: once a deliverable file exists and design files are referencing it, edits made through the proper channel flow through to every file downstream without anyone having to touch those downstream files by hand.

Civil 3D's Data Shortcuts are the mechanism that makes this sharing possible across drawings, letting surfaces, alignments, and other objects move from one file to another without manual copying. Setting up the Data Shortcuts project before any data gets imported is not optional busywork. If it is skipped or done loosely, team members lose reliable access to shared data, and anyone working offline runs into complications that are difficult to untangle later. This is the setup work that pays for itself every time a design file updates cleanly instead of breaking, and its absence causes most reference problems that appear weeks into a project.

Access control belongs in this conversation too. The survey working folder and the survey database should be open only to people with the training to use them correctly. On a team project, the create, update, and delete operations on existing-condition files should run through designated survey coordinators, not through whoever happens to be free that afternoon.

Configuring the survey database before touching ALTA point data

With the folder structure in place, attention shifts to the survey database itself, the container that governs how every imported ALTA point gets stored, edited, and eventually turned into linework. The database has to be created, named, and placed deliberately before anything is imported into it, because Civil 3D will not let a user rename or delete it from inside the software once it exists. Fixing a naming mistake means going out to the physical folder path on the network or local drive and handling it there. That limitation is easy to overlook during setup and expensive to work around once a project is underway, so it deserves attention at the very start.

The working folder path set for the project determines where every database lives, and that path needs to point to a managed network location, not someone's local desktop.

Unit settings inside the database properties carry the same weight they carried during the package audit, only now the choice has to actually get made. US Survey Foot versus International Foot needs to be set correctly before a single point goes in. Neither option is appealing. The setting belongs at the front of the process.

Opening a database for editing locks it for everyone else on the team, so the working habit that keeps a project moving is simple: open it, insert what the drawing needs, and close it again right away so the next person can get in. Survey networks, meanwhile, give the database a way to organize points into logically related groups that share the same equipment setup and control. User Defined Properties round out the database configuration, letting a firm attach project-specific metadata to points through configured property sets that carry attributes standard Civil 3D point fields were never built to hold.

Placing control points and establishing the project coordinate system

Control points are what tie every subsequent piece of ALTA data to a shared, real-world reference, and they belong in Srvy-Cntrl.dwg, placed and verified before any topographic or boundary data gets imported. Every other deliverable file in the project ends up referencing the positions established here, so an error at this stage does not stay contained. It spreads outward into the surface, the topography, and the utility files that get built afterward.

ALTA surveys state their coordinate system explicitly, typically a State Plane zone or a local assumed basis defined by the surveyor. The Civil 3D drawing's coordinate system has to match that stated system exactly. A mismatch does not throw a warning. It shifts every piece of geometry in the drawing silently, and the error can go unnoticed until something downstream does not line up with a known reference point.

This is where the distinction between survey points and COGO points matters most: survey points live inside the survey database and can only be edited from there. They cannot be grabbed and moved freely in the drawing the way other Civil 3D objects can. The practical rule that follows from this is simple. Points that exist purely as reference markers, with no analytical work planned against them, can be handled as COGO points instead.

One more constraint shapes how control data moves around a multi-drawing project: survey data cannot be Data Referenced into other drawings the way a surface or an alignment can. A team needs to settle on which of those two patterns fits the project before work gets distributed across multiple people, because switching approaches midway creates duplicate or conflicting point sets that are tedious to reconcile.

Importing ALTA point data and processing survey figures

With the database configured and control established, the ALTA point file identified during the initial audit is finally ready to come in. The import method has to match the data type that was identified earlier. CSV and TXT fieldbook exports go through the Import Points from File command. LandXML files come in through the Insert tab's LandXML option or the LANDXMLIN command, or through Import Survey Data when the target is a survey database. Whichever path applies, the column structure identified during the package audit has to match what gets selected during import, or the points will land in the wrong place without any obvious sign that something went wrong.

For a CSV or TXT import, the sequence runs like this: right-click Points in the Prospector tab and choose Import Points from File, add the file and set its type to CSV or TXT as appropriate, then select the point file format that matches the column order determined earlier, whether that is PNEZD, PENZ, ENZ, or another arrangement. A description key that is not configured correctly will still import the points, but it will file them under the wrong layers, which creates cleanup work later that is entirely avoidable at this stage.

Survey figures, the linework generated automatically from field codes, come out of the survey database through linework code sets. The database stays the authoritative record, and anything changed outside it has to be reconciled or it will be lost the next time the figures regenerate.

Every import gets logged as an event inside the database, and that log is more than a record, it is the safe path for handling a revised ALTA deliverable. The import event log functions as the project's audit trail, and treating it that way, checking it when something looks off, saves far more time than trying to reconstruct what happened from memory.

Building the existing ground surface from survey points, breaklines, and merged data

The imported points and figures exist to become a single existing ground surface drawing, the surface that every design and sheet file in the project will treat as ground truth. Building that surface usually means merging data collected at different accuracy levels, and the order in which that merging happens is the single detail most likely to get glossed over. The correct sequence starts with the largest-footprint surface, typically the lowest-accuracy data covering the widest area, and pastes higher-accuracy surfaces inside it. That order is not a stylistic preference. Reversing it degrades the surface by letting coarse data overwrite fine data instead of the other way around, and the resulting surface will carry errors into every design file that references it without any obvious warning sign.

Which creation path applies depends on what the ALTA package actually delivered. Create Surface from Points and Breaklines fits a project where the ALTA data came in as a dense point file paired with linear feature codes. Create Surface from Survey Points and Figures fits a project where the data already lives inside the survey database and the figures represent the breaklines directly. Which of the two makes sense for a given project depends on how that project is configured, including whether the dataset is large enough, or involves enough simultaneous users, to warrant keeping the source data in a separate drawing rather than working directly against the database.

Projects that need to start before ALTA data has arrived are not stuck waiting. A placeholder surface derived from USGS elevation data can stand in for conceptual or preliminary work, and once the ALTA surface is built and verified, it replaces that placeholder. Merging field survey accuracy with lower-accuracy lidar or mapping data without respecting that hierarchy produces a surface that looks complete but carries errors no one will catch until a design element built against it turns out to be wrong.

Organizing topographic and utility features into the deliverable files design will reference

The last two deliverable files, Topo-Ex.dwg and Uti-Ex.dwg, complete the base, and getting them populated correctly is what turns the whole structure into something design can rely on without constant supervision. Getting that layer assignment right at this stage is what lets xref-based referencing in downstream design files work cleanly, rather than requiring someone to chase down misplaced linework later.

Utility data drawn from the ALTA survey, existing easements and utilities shown per the title commitment, gets separated out into Uti-Ex.dwg.

What makes the whole base self-maintaining is the loop running underneath all four deliverable files: edits and updates made through the survey database and the source drawings flow through to the deliverables automatically, and every design and sheet file referencing those deliverables picks up the changes without anyone redistributing anything manually. That loop depends on the original file structure having been built correctly from the start and on everyone going back through the proper source to make edits. Project templates assembled in advance, drawing templates for each file type, CAD standards, and Data Shortcut configurations already set up, cut down the work needed at this final stage and keep every deliverable consistent with the others.

Access discipline matters here just as much as it did at the very beginning of the process. Only personnel who understand the full workflow should be adding to or modifying existing-condition files, because a base built by someone without that knowledge introduces reference problems that do not announce themselves. The sequence described across this entire process, auditing the ALTA package, structuring the folders, configuring the database, placing control, importing data, building the surface, and organizing the feature files, exists to prevent exactly that outcome. Getting this sequence right once protects every hour of design work that follows it.