What Information Can Be Lost When Converting GIS Formats?

GIS format conversion can lose information even when every feature appears in the output.

A conversion is not merely changing .shp to .gpkg or .geojson to .parquet; it translates between data models with different rules for geometry, coordinate systems, field types, nulls, identifiers, styling, metadata, and storage structure.

The safest assumption is therefore:

successful export proves that an output file was created, not that the source and destination are semantically identical.

Attribute schema can change

Formats support different field-name lengths, data types, numeric ranges, date/time representations, arrays, nested structures, and null semantics. As a result, a shapefile export can shorten field names, a JSON-based format may not distinguish integer widths the same way a database does, a timestamp with timezone can become a plain string, and large integers can exceed what some consumers safely represent.

After conversion, inspect both field names and field types—not only whether the columns exist.

Null, empty, zero, and missing are not interchangeable

One system may distinguish:

• null — unknown/no value;

• empty string — known text with zero characters;

• zero — a numeric value;

• missing property — field not present for the record.

A target format or library may collapse some of those states, materially changing analysis when, for example, nulls are excluded from averages or zero has domain meaning.

CRS metadata can be simplified or lost

Coordinate reference systems can be represented as EPSG identifiers, WKT, PROJJSON, GeoTIFF keys, sidecar files, or format-specific metadata.

A conversion may:

• drop the CRS;

• replace a detailed CRS definition with a generic identifier;

• change axis-order conventions;

• omit coordinate epoch;

• reproject coordinates when the user expected only format translation.

Always verify both the numeric coordinates and the resulting CRS metadata.

Geometry capabilities differ

The target may not support every geometry type or dimension present in the source.

Potential losses include:

• Z elevation;

• M/measure values;

• curves or circular arcs;

• mixed geometry collections;

• multiple geometry columns;

• ring orientation semantics;

• empty geometries;

• geometry types outside the target's supported model.

Consequently, software may linearise curves, drop dimensions, promote single features to multi-geometries, or reject unsupported records.

Precision can change

Coordinates can be rounded intentionally or indirectly through a lower-precision numeric representation, text formatting, simplification, or export options. Rendered maps may still look identical, even while small coordinate changes affect topology, snapping, area, or downstream overlays.

Do not evaluate precision only at normal screen zoom.

Text encoding can corrupt names

Legacy formats and poorly documented exports can disagree about character encoding.

As a result, accented characters, non-Latin scripts, and punctuation may become replacement symbols or mojibake even when geometry survives perfectly.

Check representative international or accented names after conversion, not just ASCII fields.

Stable identifiers can disappear

A row number is not necessarily a durable feature identifier, since sorting, filtering, exploding multipart geometry, or rewriting a database table during export can change implicit row order. If downstream systems depend on identity, preserve an explicit stable ID and verify uniqueness after conversion.

Styling and application behaviour are often outside the data format

KML can carry presentation instructions that GeoJSON does not standardise. A desktop GIS project can store labels, symbology, joins, filters, and layer ordering that are not part of the underlying dataset. Vector tiles may contain only the attributes required for publication.

Exporting the data does not necessarily export the map, a distinction that becomes especially important when a user expects a converted file to reproduce the exact appearance or interaction of the source application.

Raster conversions have their own losses

Raster formats can differ in:

• cell type and bit depth;

• NoData representation;

• compression;

• colour tables;

• overviews;

• internal masks;

• band metadata;

• geotransform and CRS encoding.

Lossy image compression can also change pixel values, making it unsuitable for analytical rasters even if the image looks acceptable.

Validate conversion with a small checklist

After conversion, compare source and target for:

1. feature or cell counts;

2. geometry types and dimensions;

3. extent and CRS;

4. field names and types;

5. null counts;

6. identifiers;

7. representative international text;

8. numeric ranges and precision;

9. metadata and provenance;

10. styling or semantic information expected by downstream users.

For high-value datasets, run domain-specific checks too: topology, known control features, raster statistics, or selected spatial calculations.

Keep the source and record the transformation

The safest workflow treats conversion as a derived representation.

Keep the original source, record the target format and options, and preserve enough provenance to repeat the conversion. If the target is optimised for web delivery—simplified GeoJSON, vector tiles, PMTiles, or another publication artefact—do not silently promote it to the authoritative analytical dataset.

Different formats are valuable precisely because they make different trade-offs. Conversion is reliable when those trade-offs are explicit.

Related content

• What Is a Shapefile? — legacy format constraints

• KML vs GeoJSON — presentation versus lightweight feature exchange

• GeoParquet vs GeoJSON — analytical versus delivery-oriented trade-offs