On this page
Short answer
We choose a delivery format around how the recipient will edit, display, query or discover the data. GeoPackage can package GIS layers and tables; GeoJSON supports web feature exchange; COG organizes rasters for selective access; STAC describes assets for discovery. They solve different parts of a handover, and none guarantees that the underlying data is correct.
- Agree the receiving application and acceptance checks before selecting a format.
- Standard GeoJSON uses longitude/latitude, not arbitrary projected eastings and northings.
- Metadata, reference information and a tested sample are part of the deliverable.
Who this is for: GIS analysts, engineering consultants and teams specifying or accepting geospatial data.
Match the format to the receiving workflow
This is an editorial selection aid, not a rule that one format should replace every other delivery. A project may need several complementary outputs. Test a small representative package in the receiving application before processing the complete collection.
| Need | Starting choice | Check before delivery |
|---|---|---|
| Multiple editable layers and tables | GeoPackage | Layer names, schema, reference records and supported extensions |
| Web/API feature exchange | GeoJSON | Coordinate order, RFC 7946 reference, identifiers, geometry and size |
| Selective access to large imagery or elevation | Cloud Optimized GeoTIFF | Tiling, overviews, georeferencing, NoData and range-capable serving |
| Discoverable spatial/temporal asset collection | STAC plus the actual assets | Extent/time, asset links, media types and metadata completeness |
Technical references: OGC: GeoPackage 1.4 specification; IETF: RFC 7946 GeoJSON; OGC: Cloud Optimized GeoTIFF standard; OGC: STAC Community Standard.
Preserve the meaning of vector coordinates and attributes
GeoPackage is a SQLite-based geospatial container with defined content and spatial-reference structures. It can be useful when several layers and related tables need to travel together. Agree any extensions and check how the receiving software implements them.
RFC 7946 GeoJSON uses WGS 84 longitude and latitude in decimal degrees, with longitude first. Its optional third coordinate is ellipsoidal height. Do not put projected eastings/northings into an ordinary standards-conforming GeoJSON and assume a downstream web map will infer the reference. More decimal places do not establish better positional accuracy.
Technical references: OGC: GeoPackage 1.4 specification; IETF: RFC 7946 GeoJSON.
COG and STAC are complementary
COG organizes a georeferenced raster using structures such as tiles and overviews so compatible clients can request the portions they need through suitable HTTP range access. Uploading a TIFF or changing its filename does not demonstrate that the data or serving arrangement supports that workflow.
STAC standardizes a description of assets with spatial and temporal context. A catalogue can help a client discover the appropriate image or dataset, but the metadata is not the image itself. Check that asset links resolve, their types are accurate and the spatial/temporal information describes the actual files.
Technical references: OGC: Cloud Optimized GeoTIFF standard; OGC: STAC Community Standard.
Deliver a manifest another team can understand
These are our recommended handover fields. The exact package should be agreed for the project. A short, specific manifest is more useful than a generic statement that the data is GIS-ready.
- Name each dataset, layer and version, and explain its intended use.
- State source, acquisition period, permitted use or licence, and processing history.
- Record horizontal and vertical references, axes, units and relevant epoch information.
- Describe fields, identifiers, coded values, missing values and geometry types.
- Explain quality checks, known exclusions, uncertainties and interpretation limits.
- Include file sizes or checksums where useful, and identify the receiving software/version used for the test.
Validate the format and the content separately
- Open a representative sample in the recipient's actual software.
- Check feature counts, geometry validity, identifiers and attribute types.
- Inspect known features and compare the reference information with project requirements.
- For rasters, examine NoData, pixel values, georeferencing and overview behaviour.
- For catalogues, test asset links, extents, dates and media types.
- Record acceptance results and unresolved gaps before delivering the complete set.
Technical references: OGC: GeoPackage 1.4 specification; IETF: RFC 7946 GeoJSON; OGC: Cloud Optimized GeoTIFF standard; OGC: STAC Community Standard.
Common questions
Can GeoJSON contain my local projected coordinates?
Ordinary RFC 7946 GeoJSON uses WGS 84 longitude/latitude. Transform appropriately for that exchange, or agree a format and software workflow that preserves the required projected reference.
Does STAC replace the image files?
No. STAC describes and links assets. The actual imagery or other data still needs to exist and remain accessible through the referenced asset links.
Does a valid GIS file prove the data is accurate?
No. Format and schema checks establish only part of acceptance. Reference consistency, source quality, positional checks, completeness and fitness for the intended use must be evaluated separately.
Official references
Sources checked 1 November 2026. The linked publishers remain the authority for their specifications and services.
- OGC: GeoPackage 1.4 specification
Container structure, spatial reference records, content and extension conventions.
- IETF: RFC 7946 GeoJSON
Standard coordinate reference/order, optional height and numerical-precision cautions.
- OGC: Cloud Optimized GeoTIFF standard
Raster organization and selective web access requirements.
- OGC: STAC Community Standard
Spatial/temporal asset metadata and catalogue structure.