GNSS GeoJSON export quality: coordinates, geometry and provenance

Understand what GeoJSON standardises

GeoJSON is a text-based format for geographic features and their properties. Under RFC 7946, positions use WGS84 longitude and latitude in decimal degrees, in that order. This is a specific exchange convention, not permission to place any coordinate pair inside a geometry array. Projected eastings and northings must be transformed before a standards-conforming export.

Identify the source reference and intended use of the file before exporting. A local survey grid, a projected CRS and a geographic reference may all describe the same site through different values. Keep the original survey dataset and reference metadata. GeoJSON is useful for exchange and web mapping, but it should not replace the complete observation archive when that archive contains additional survey evidence.

Continue learning Exporting GNSS data to GIS without losing its meaning

Transform values rather than relabelling them

Assign the correct source CRS to the source dataset, then perform an appropriate transformation to the GeoJSON geographic reference. Record the operation used, including relevant model versions and epoch information where applicable. Assigning a WGS84 label to unchanged projected coordinates does not convert them. Test representative known points after transformation.

Check axis order explicitly at the export boundary. Some software and reference definitions use different conventions internally. The delivered GeoJSON coordinate array must follow the format’s longitude-latitude order. A point that plots in the wrong hemisphere is an obvious warning, but subtler axis or reference mistakes can still produce plausible-looking geometry. Numeric range checks are useful alongside documented reference handling.

Continue learning Shapefile limitations that matter in GNSS survey handovers

Define the role of a third coordinate

RFC 7946 permits an optional third position value representing height relative to the WGS84 ellipsoid. Do not silently place a geoid-derived engineering elevation in that slot and assume every consumer will interpret it correctly. If the project’s elevation has another reference, preserve it as a clearly named property with its units and vertical reference, or use an explicitly agreed exchange workflow.

Keep missing heights distinguishable from zero. A zero value is a real coordinate value, not a generic marker for unknown elevation. Review whether the receiving application uses or ignores third coordinates. The export should communicate the survey’s height meaning honestly rather than adding an unexplained number merely because the source point layer is three-dimensional.

Continue learning Using GeoPackage for a structured GNSS survey archive

Validate geometry structure and feature meaning

Check that each feature uses the intended geometry type and valid coordinate nesting. A point asset should not accidentally become a line, and a surveyed boundary should not be reduced to its centroid without an explicit purpose. For polygons, review closure and topology through suitable validation tools. Technical validity does not prove that the geometry represents the correct physical object.

Inspect feature counts and identifiers against the source. Confirm that multipart objects, empty geometries and inaccessible areas are handled according to the project’s rules. Avoid silently dropping difficult records. Preserve an issue list for excluded or transformed features so another reviewer can understand why the exchange file differs from the full survey database.

Continue learning Designing a geodatabase schema for GNSS point observations

Preserve useful attributes and identifiers

Use stable feature and observation identifiers in properties. Keep text identifiers as text where leading zeros or long codes matter. Include observation date, method and quality status appropriate to the receiving workflow. Do not expose a generic accuracy property whose meaning is unclear; document whether a value is an instrument estimate, independent check result or project classification.

Keep attributes concise but sufficient to interpret the geometry. Photographs and raw observations may remain in another archive, linked through identifiers or an agreed reference. Test special characters and null values in the receiving application. A valid JSON file can still lose operational meaning if an asset identifier changes type or an unknown value is converted into an apparently measured zero.

Continue learning Exporting GNSS data to GIS without losing its meaning

Balance coordinate precision and file size

Choose output decimal precision according to the intended use and supported evidence. More digits do not create more accuracy. Excessive rounding can alter geometry, while unnecessary digits enlarge files and imply unwarranted detail. Test the effect of the chosen precision on representative points and boundaries instead of applying a universal rule without considering the project.

For large datasets, review whether GeoJSON is the most practical delivery format for every use. A browser exchange layer and an authoritative survey archive can be different products. Keep a complete dataset in a suitable format and create a purposeful GeoJSON export. This avoids sacrificing reference or observation metadata simply to make one file serve every workflow.

Continue learning Shapefile limitations that matter in GNSS survey handovers

Test the file in an independent consumer

Validate JSON syntax, geometry structure and coordinate ranges, then open the file in the intended web or GIS application. Compare known locations, identifiers and attributes against the source. Reimport a sample and inspect the geometry values. A successful export message does not demonstrate that the receiving system interprets the file as intended.

Check third-coordinate handling, null values and attachment references specifically. Review the file’s extent and any features near unusual coordinate boundaries. Keep the validation results with the release. The test should confirm both standards conformity and the project’s data meaning, since those are related but different requirements.

Continue learning Using GeoPackage for a structured GNSS survey archive

Deliver an exchange file with provenance

Provide a short metadata note identifying the source survey, transformation operation, coordinate convention, height handling and attribute dictionary. State the observation period and quality assessment. Keep the source dataset and original reference definitions available separately. This lets recipients use the GeoJSON without assuming it contains the full survey history.

Version the export and preserve the process used to create it. If a coordinate or schema correction is made, identify the affected release. A dependable GNSS GeoJSON file is a documented transformation of survey evidence into an interoperable exchange representation. Its usefulness depends on correct reference handling and clear semantics as much as on valid brackets and commas.

Continue learning Designing a geodatabase schema for GNSS point observations

Catch projected coordinates before publication

Suppose a draft GeoJSON point contains values that look like a six-digit easting and a seven-digit northing. Stop and review the source CRS rather than swapping the numbers or dividing them by a convenient factor. The file likely contains projected coordinates that have not been transformed to the format’s geographic convention. Changing the geometry type or adding a CRS label does not resolve that standards mismatch.

Return to the correctly referenced source dataset and perform the documented transformation. Test several known points and compare attributes after export. Preserve the rejected draft in the issue record if it helps explain the correction, but release only the validated file. This simple boundary check prevents a syntactically valid exchange file from carrying fundamentally uninterpretable positions into downstream web maps.

Check that the revised file contains the intended feature count and stable identifiers, especially if the export was recreated from a different working layer. A correct coordinate transformation does not protect against exporting the wrong subset. Compare several records with the source and review the complete extent. Keep the transformation settings and validation outcome with the release. This turns a one-time correction into a repeatable export process and helps a future operator distinguish the authoritative source from a rejected draft that may still remain in the working folder.

Continue learning Exporting GNSS data to GIS without losing its meaning