Shapefile limitations that matter in GNSS survey handovers

Choose the format for the information being delivered

Shapefile remains common in GIS exchange, but a survey dataset may contain more information than the format can preserve conveniently. Identify the required geometry, attributes, observation history and attachments before exporting. A simple accepted-position layer may be a reasonable exchange product, while the full GNSS observation archive may need a richer database structure.

Keep an authoritative source dataset and create a deliberate export view. Do not let the limitations of one recipient’s format silently redefine the project’s data model. Document what the exchange file contains and what remains in the complete archive. This allows the receiving team to use a practical format without assuming it carries every part of the survey evidence.

Continue learning Exporting GNSS data to GIS without losing its meaning

Plan field names and their mapping

Traditional Shapefile attributes are stored in a DBF table with restrictive field naming. GDAL documents a ten-character limit for the underlying attribute names and explains how truncated names can be made unique. Do not assume long source names will survive unchanged. Newer sidecar conventions or software-specific aliases should not be relied on without testing the recipient’s actual tools.

Create an explicit mapping from full source names to exported names. Check for collisions between similar names after truncation. A field such as observation_date and another such as observation_status should not become ambiguous merely because their prefixes match. Provide a data dictionary using the delivered field names so recipients can interpret the file without access to the authoring application.

Continue learning GNSS GeoJSON export quality: coordinates, geometry and provenance

Review attribute types and unknown values

Check how dates, long identifiers, numeric precision and null values are represented by the intended export and receiving software. The format supports a narrower set of attribute types than many modern databases. A timestamp, list or related observation record may require a separate agreed representation. Test real edge cases rather than only a simple row with short text.

Keep identifiers as text where their meaning requires leading zeros or long codes. Confirm that long notes are not truncated and that unknown values remain distinguishable from zero. If a field cannot be preserved faithfully, document the conversion or deliver it through another file. A technically valid export can still be semantically damaged when attributes lose their original type or meaning.

Continue learning GNSS surveys across UTM zone boundaries

Deliver all required companion files

A Shapefile dataset consists of related files rather than only the file ending in .shp. The geometry, index and attribute components must stay together, along with relevant projection and encoding information. Use a clear package or directory arrangement that preserves matching base names. A recipient who receives only the geometry component may lose attributes or fail to open the dataset properly.

Test the handover from the delivered location, not only from the authoring folder. Confirm that all companion files are included and no similarly named older version is mixed into the package. Use a release manifest where several layers are supplied. This simple file-management step prevents avoidable errors that can otherwise look like a software compatibility or coordinate problem.

Continue learning Handing GNSS survey coordinates to CAD teams without losing meaning

Preserve reference meaning beyond the projection file

Include a projection definition, but also provide metadata for datum realisation, coordinate epoch, local grid settings and height convention where relevant. A projection sidecar may not communicate the complete survey reference chain. State whether the geometry contains ellipsoidal height, another elevation type or only horizontal coordinates.

If the data are transformed for the recipient, record the source, target and operation used. Preserve the original survey dataset. Do not assign a target CRS label to unchanged values. Test known points after export and import. The format’s ability to carry a reference definition does not remove the need to verify that the definition actually describes the delivered numbers.

Continue learning Exporting GNSS data to GIS without losing its meaning

Check geometry types and feature relationships

Review how the export handles multipart features, three-dimensional coordinates and geometry types. Keep physical feature meaning clear. A utility asset, a survey observation and a derived line should not be merged into one generic layer simply to simplify delivery. Shapefile also does not replace the relationships in a richer observation database.

When related tables or attachments are required, provide a documented key and an agreed companion structure or choose another format. Test that the receiving team can join the records correctly. A point layer with a photo filename is useful only if the file can be found and matched. Preserve stable identifiers through every export step.

Continue learning GNSS GeoJSON export quality: coordinates, geometry and provenance

Validate the round trip in the receiving workflow

Export a representative sample containing long names, leading zeros, special characters, dates, unknown values and relevant geometry variations. Open it in the actual receiving application where possible. Compare field names, types, values, feature counts and coordinates with the source. Review a few known locations and important attributes manually.

Record any changes introduced by the format and confirm whether they are acceptable for the intended use. Do not assume that success in the exporting application proves interoperability. The receiving tool may interpret encoding, dates or field widths differently. A short sample test before full delivery is more efficient than repairing a large handover after the recipient begins using it.

Continue learning GNSS surveys across UTM zone boundaries

Provide a format-aware handover note

Include the data dictionary, source reference, height definition, export mapping and limitations with the layer. State whether it is a simplified accepted-position product or a complete observation record. Identify any separate tables or attachments and explain their keys. Keep unresolved issues visible rather than hiding them in an informal email or personal notebook.

Archive the complete source and issued export together. If a richer format such as GeoPackage is also supplied, explain which package is authoritative and how the two correspond. A reliable Shapefile handover is possible when its limitations are handled deliberately. The goal is to preserve survey meaning through the exchange, not merely to produce files with a familiar extension.

Continue learning Handing GNSS survey coordinates to CAD teams without losing meaning

Catch a truncated identifier before release

Suppose a long asset code looks correct in the first few rows but later records end at the same character limit. Compare the exported field width with the source and inspect the actual values. Do not rebuild identifiers from neighbouring rows or assume the missing suffix is unimportant. The code may be the only reliable link to photographs and maintenance records.

Revise the export design or use a format that preserves the required values, then repeat the round-trip test. If a shortened exchange identifier is necessary, create a controlled cross-reference to the full stable identifier. Keep that mapping with the release. This protects object identity and avoids a map that appears spatially correct while its records can no longer be reconciled with the asset system.

Review joins to companion tables after the identifier correction. A spatial layer may now carry the full code while an earlier exported table still contains the truncated version. Reissue related files coherently and test a few photograph or asset-system links. Keep the mapping between old and corrected identifiers if recipients may already have used the first release. This preserves continuity without pretending the damaged export never existed and gives downstream teams a practical way to reconcile records they created before the correction was issued.

Continue learning Exporting GNSS data to GIS without losing its meaning