At some point, every mechanical or civil engineer gets handed a shapefile or GeoJSON and told to “do something with it.” Usually it is site boundary data for a facility layout, parcel boundaries for a land survey, drone-acquired point cloud footprints, or utility infrastructure from a municipal dataset. None of these came from SolidWorks or AutoCAD. They came from GIS, and they arrived in a format you may never have opened before.

This post covers what you actually need to know — not a GIS course, not a QGIS tour, not a history of spatial data. Specifically: EPSG codes, why shapefiles cause quiet problems, and the command-line tools that replace most of the manual work.

EPSG codes: the most confusing thing that is actually simple

When you receive geospatial data, the most important question is: what coordinate reference system (CRS) is this in? If you combine two datasets in different CRSes without reprojecting, the geometry will be in the wrong place — sometimes by centimeters, sometimes by hundreds of kilometers.

EPSG codes are just numeric identifiers for coordinate reference systems. The standard is maintained by the EPSG Geodetic Parameter Dataset (now the IOGP). You do not need to understand the math; you need to know three codes:

EPSG 4326 — WGS84

Latitude and longitude in decimal degrees. This is what GPS gives you. Web APIs return it. GeoJSON defaults to it per RFC 7946. When someone says “coordinates,” they almost always mean WGS84.

Units are degrees, not meters. (40.7128, -74.0060) is New York City. You cannot do metric distance calculations directly on these coordinates without reprojecting.

EPSG 3857 — Web Mercator

The projection used by Google Maps, OpenStreetMap tile servers, and most web mapping backgrounds. Units are meters (at the equator — distortion increases toward the poles). If you are overlaying your data on a tile-based basemap, you will eventually encounter this. It looks like WGS84 but is not.

UTM zones — EPSG 32601 through 32660 (north) and 32701 through 32760 (south)

The Universal Transverse Mercator system divides the Earth into 60 zones, each 6° of longitude wide. Within a zone, units are meters and the distortion is low enough for engineering work. UTM Zone 17N (EPSG 32617) covers much of the eastern US; Zone 32N (EPSG 32632) covers Germany and neighboring areas.

If your data is a local site survey or parcel boundary, it is probably in a UTM zone or a national grid (OSGB36/27700 in the UK, RD New/28992 in the Netherlands). UTM data has coordinates in the millions of meters (easting/northing), not in degrees.

How to check the CRS of a file you received:

ogrinfo -al -so your_file.shp

This prints the layer summary including the coordinate system. Look for the AUTHORITY["EPSG","<code>"] line. If you see 4326, the data is in WGS84. If you see 32617, it is UTM Zone 17N. If the .prj file is missing from a shapefile delivery, the CRS is unknown and the sender needs to confirm it.

Why shapefiles cause problems you do not expect

The shapefile format was designed in the early 1990s for ArcInfo. It is still the most common format for GIS data exchange. It is also a minefield for engineers who expect file formats to faithfully preserve what is put into them.

Field name truncation. The .dbf attribute table limits field names to 10 characters. If you receive a shapefile converted from another format, field names longer than 10 characters will be silently truncated. MATERIAL_TYPE becomes MATERIAL_TY. INSTALLATION_DATE becomes INSTALLATIO. There is no error, no warning. You look at the data and wonder where your columns went.

No true nulls. The dBASE III format used by shapefiles does not support null values in numeric fields. Missing values are represented as 0, which is indistinguishable from actual zero measurements unless you know to check. String fields use spaces as null stand-ins. If your data has meaningful zeros and genuine missing values, shapefiles will conflate them.

Multi-file fragility. A single shapefile layer is actually at minimum three files: .shp (geometry), .shx (index), .dbf (attributes). Usually there is also .prj (projection), .cpg (encoding declaration), and potentially .sbx/.sbn for spatial indices. Send someone just the .shp file and they will open it in QGIS only to find no attribute data and no coordinate system. Zip the folder, not the individual file.

2 GB component limit. Each component file has a hard limit. Large datasets hit this. The .dbf file tends to hit it first in attribute-heavy data. GeoPackage handles files of any size within filesystem limits.

Single geometry type per layer. One shapefile stores points, or lines, or polygons — not a mix. Mixed-geometry datasets from GeoJSON or GeoPackage must be split when converting to shapefile, and the split is not always obvious to automated tools.

For a detailed breakdown of the data loss that happens during GeoJSON-to-shapefile conversion, see GeoJSON to Shapefile: The Field Truncation Problem Nobody Warns You About. If you are delivering shapefiles to another party and need to ensure the conversion is clean, GeoConvert handles the GDAL conversion pipeline with validation and CRS preservation — useful when you are responsible for the output quality.

What to use instead

GeoJSON is a single file, human-readable, and supported everywhere. It is RFC 7946 compliant when field names and coordinate order are handled correctly. The limitation is performance: GeoJSON is verbose (it is JSON) and slow to parse at scale. Use it for datasets under a few thousand features, for API payloads, and for anything you want to inspect in a text editor.

GeoPackage is an SQLite database with a .gpkg extension. It stores geometry, attributes, multiple layers, raster data, and metadata in a single file with no component splitting. Field names can be up to 1000 characters. It handles nulls correctly. It scales to large datasets. The GeoParquet vs GeoPackage vs Shapefile decision tree covers when to choose each format for a given project.

FlatGeobuf (.fgb) is the right choice when you have large datasets that will be queried via HTTP range requests without downloading the full file — a streaming use case relevant to web-hosted datasets. For local project exchange, GeoPackage is simpler. See FlatGeobuf for large GIS datasets for the performance comparison.

Five ogr2ogr commands that replace most of the manual work

GDAL’s ogr2ogr is the command-line tool for geospatial format conversion, CRS reprojection, and layer filtering. It is installed with GDAL, which is available via conda, homebrew, apt, and the OSGeo4W installer on Windows. The full command reference covers the complete option set; these five cover most engineer use cases.

1. Inspect any file before touching it

ogrinfo -al -so input.gpkg

Prints layer names, feature count, geometry type, CRS authority code, and extent. Run this first on any file you receive. -al lists all layers; -so prints summary only (no individual features).

2. Convert shapefile to GeoPackage, preserving CRS

ogr2ogr -f "GPKG" output.gpkg input.shp

The CRS from the .prj file is preserved automatically. The output is a single file. Field names are preserved without truncation.

3. Reproject to WGS84

ogr2ogr -f "GeoJSON" output.geojson input.shp -t_srs EPSG:4326

-t_srs sets the target CRS. The source CRS is read from the .prj file. If the .prj is missing, add -s_srs EPSG:<code> to declare it explicitly.

4. Convert GeoJSON to shapefile for legacy delivery

ogr2ogr -f "ESRI Shapefile" output_folder/ input.geojson

This is the delivery case — when the receiving party requires a shapefile and you are working from GeoJSON or GeoPackage. The output goes into a folder (ogr2ogr creates multiple files). Check the field names in the .dbf for truncation after conversion.

5. Spatial filter: clip to a bounding box

ogr2ogr -f "GPKG" clipped.gpkg input.gpkg -spat -74.1 40.6 -73.9 40.8

-spat takes xmin ymin xmax ymax in the source CRS. Useful for extracting a project area from a large municipal dataset without loading the whole file.

QGIS for engineers who are not GIS specialists

QGIS is a full desktop GIS application. You do not need to learn all of it. For an engineer working with site data, these five operations cover most situations:

  1. Open a file: Layer → Add Layer → Add Vector Layer (or drag-and-drop any .shp, .gpkg, .geojson onto the canvas).
  2. Check the CRS: Right-click the layer → Properties → Information tab. Find the coordinate reference system entry.
  3. Reproject a layer: Right-click → Export → Save Features As. Change the CRS field to EPSG:4326 or your target system.
  4. Attribute table: Right-click → Open Attribute Table. This is how you inspect fields and values — equivalent to opening the .dbf in Excel, but without risking corruption.
  5. Export to a different format: Right-click → Export → Save Features As. Choose Format (GeoPackage, ESRI Shapefile, GeoJSON, etc.), set the output path and CRS.

These five operations cover: receiving data, verifying it, reprojecting it, inspecting attributes, and delivering it in the format your counterpart needs. QGIS has more — topology checking, geoprocessing, raster analysis — but an engineer who knows these five can handle the geospatial component of most facility or infrastructure projects.

The five mistakes engineers make with GIS data

1. Combining datasets without checking CRS first. If your facility footprint is in UTM 17N and the parcel boundary you received is in WGS84, overlaying them without reprojection puts your building on the wrong continent. Check CRS before any analysis. ogrinfo -al -so takes ten seconds.

2. Trusting shapefile field names without checking the source schema. If the original data had fields named INSTALLATION_DATE_UTC and MATERIAL_GRADE_ASTM, the shapefile delivery has INSTALLATIO and MATERIAL_GR. Ask for the field name mapping or the original GeoPackage.

3. Assuming CSV coordinates are WGS84. Survey exports, GPS logger exports, and facility CMMS systems all provide coordinates in different systems. A CSV with “Easting” and “Northing” columns is almost certainly in a projected system, not decimal degrees. Plotting them on a WGS84 basemap without reprojection produces points in the South Atlantic Ocean.

4. Treating the .prj file as optional. If someone sends you a shapefile without the .prj, the geometry is geometrically correct but locationally undefined. You can guess the CRS from the coordinate ranges (values near ±180/90 suggest WGS84; values in the millions suggest UTM or a national grid), but guessing introduces risk. Require the CRS from the data provider before using the file.

5. Round-tripping through shapefile. If you receive a GeoPackage, do your work, then export to shapefile for delivery, then the recipient converts back to GeoPackage — field names are truncated in the shapefile step and stay truncated forever. Keep the full-fidelity format throughout the pipeline; only convert to shapefile for the final delivery, and document the field name mapping.

When you need to deliver a shapefile to someone else

The format is not going away. Municipal GIS portals, government agencies, and legacy CAD-linked workflows still require shapefiles. When you need to produce one from GeoJSON or GeoPackage data — particularly for a non-technical recipient who will load it in ArcGIS — GeoConvert runs the GDAL conversion pipeline with geometry validation, CRS preservation, and RFC 7946 attribute mapping. It handles the multi-file packaging so the recipient gets a correctly assembled zip. For programmatic conversion in a pipeline, ogr2ogr directly is faster; GeoConvert is useful when the output quality needs to be verified and the person running the conversion is not a GIS specialist.

The three things to know before handing off any GIS file: what CRS it is in, what the field names are (and whether they were truncated), and whether null values survived the format conversion. Everything else in GIS builds from those three.