Set the project's coordinate system — CivilCraft help

A project's coordinates are plain numbers until you say what they mean. Setting the coordinate system never moves anything: it tells CivilCraft that, for example, E 6,150,000 N 2,080,000 are California zone 6 state plane coordinates in US survey feet. Once it knows:

the status bar shows the latitude and longitude of the pointer,
GIS files in other systems (shapefiles, GeoJSON, GeoPackage, elevation grids, LiDAR) are converted into the project as they open,
map layers can be drawn under the plan (Show map layers under the plan),
exports to GIS formats carry the system (a .prj for shapefiles, the EPSG code for GeoPackage and GeoTIFF).

Pick the system

Choose Coordinates in the GIS group of the toolbar. The Coordinate system dialog opens. At the top it says what the project is in now, or None — coordinates are just numbers.
Find the system one of these ways:
- Search: type the EPSG code (2277, EPSG:2277) or words from the name (texas central, utm 14n, lambert-93). Codes list from the one you typed; words list systems whose name has every word.
- Systems these coordinates fit (when the project has points or a surface): CivilCraft reads the middle of your project in every system of the project's unit family and lists the ones whose area of use holds it. State plane coordinates usually fit only a few zones: a project in Texas at E 3,115,000 N 10,070,000 US survey feet fits the four Texas Central variants (NAD83, NAD83(2011), HARN, NSRS2007). Each entry shows where your project's middle would be.
- Near (lat, long) and Suggest: type where the site is, for example 30.27, -97.74 or 30°16′N 97°44′W, and CivilCraft lists the projected systems whose area holds it, national and state grids first.
- Read a .prj file…: open the .prj that came with a shapefile or a drawing. CivilCraft matches it to its list by the projection maths (so a .prj that names a datum differently still finds the right system) and says which one it is; when nothing matches exactly, the file's own description is used. You can also drop a .prj on the dialog, or open or drop one on the plan by itself.
Click a system in the list. Under Chosen it shows the name, EPSG code, unit, how well its datum is tied to WGS 84, its area of use in latitude and longitude, and where your project's middle falls in it.
Leave Grid selected (most projects; see Ground and local coordinates for the others) and choose Apply.

The status bar now shows the pointer's latitude and longitude next to E and N. Setting the system is one undo step: ⌘ZCtrl+Z takes it back.

Change or remove the system

Open Coordinates again, pick another system and choose Apply. When the project has points or a design, CivilCraft asks Are the coordinates in … already?

Yes — nothing moves: the numbers stay as they are and only their meaning changes. Use this when the old system was picked by mistake.
No — convert them: every survey point, breakline, boundary, alignment PI, pad corner and structure is converted from the old system into the new one, in one undo step. A surface read from LandXML as triangles cannot be converted; rebuild it from the points first.

Remove the system takes the system away (nothing moves). GIS layers already in the project stay where they are.

Latitude and longitude in the status bar

While the project has a system, the status bar shows the pointer's latitude and longitude on WGS 84, for example 30°18′00.00″ N 97°42′00.00″ W. Choose decimal degrees instead under Settings, CivilCraft, Latitude and longitude (CivilCraft settings). With ground or local coordinates the readout goes through that step first, so it is right for the point under the pointer.

How good the datum shift is

Latitude, longitude, GeoJSON and map layers are all on WGS 84. Each system's tie to WGS 84 is shown in the dialog:

What the dialog says	What it means
WGS 84 itself	No shift at all.
NAD83 is taken as WGS 84	The two differ by a meter or two in most of North America, a few meters at most. Good for map layers and site context; not for survey control.
Known to about n m (EPSG's figure)	A published shift; map layers and GeoJSON can be off by about that much.
Not known for this datum	There is no published shift without a grid file: map layers and GeoJSON may be off by hundreds of meters.

Your project's own coordinates never go through a datum shift: only what is converted to or from latitude and longitude does. Vertical datums and geoid models are not handled (elevations are never converted). Grid-shift files (OSTN15, NADCON and similar) are not used: where the best shift needs one, the list carries a rougher published shift instead and the dialog shows its accuracy (NAD27 systems, for example, about 20 m).

What was checked

Every conversion was compared with PROJ (pyproj 3.7.1 with PROJ 9.5.1), the coordinate library most GIS programs use, on over 330 systems: state plane in US survey feet and feet, UTM north and south, Lambert-93, British National Grid, GDA2020 MGA, New Zealand Transverse Mercator and web Mercator among them. Eastings and northings agree to 1 cm with the same datum shift (most to well under 1 mm), and the projection maths agree with PROJ's own definitions to 1 cm.
.prj files written by PROJ in both common forms (ESRI and OGC) were read back for 105 systems: 208 of the 210 matched their exact EPSG code and the other two a system with the same maths on the same ellipsoid. .prj files CivilCraft writes are read by PROJ as the same system. ESRI .prj files for polar stereographic systems (UPS, Alaska polar) cannot be read; pick those systems by code.
The latitude and longitude in the status bar matched PROJ to 0.01″ in the browser.