Convert GeoJSON with GDAL: a practical guide to format conversion, reprojection, and validation
GDAL provides command-line and programming interfaces for converting GeoJSON into other vector formats and transforming geographic data during the same operation. The most commonly used utility is `ogr2ogr`, which can read GeoJSON, write formats such as GeoPackage, Shapefile, FlatGeobuf, and GeoJSON, reproject geometries, select features, reduce attributes, and apply geometry-related options. This guide presents a repeatable workflow: inspect the input, choose an output format, make coordinate reference systems explicit, run a bounded conversion, validate the result, and automate the process when the data becomes part of a larger geographic pipeline.
GeoJSON is convenient for exchanging geographic features, especially in web applications and APIs, but it is not always the best format for storage, analysis, or bulk processing. A large GeoJSON file can be awkward to edit, slow to query repeatedly, or unsuitable for workflows that require spatial indexes and multiple layers. GDAL’s vector tools provide a dependable way to move that data into a more appropriate format while optionally changing its coordinate reference system, selecting a subset of features, reducing fields, and preserving or deliberately discarding parts of the original JSON representation.
How EDK fits
For: GIS practitioners, data engineers, Python developers, analysts, and application developers who need to convert GeoJSON files or documented GeoJSON services into analysis-ready or operational vector formats.
Converting GeoJSON is a practical boundary operation between a source dataset and a usable representation of the physical world. A GeoJSON file may contain roads, buildings, parcels, waterways, service locations, incidents, or other features, but the format alone does not make those features easy to search, compare, measure, or combine. GDAL helps establish a reliable handoff: inspect what the source actually contains, make its coordinate system explicit, preserve the attributes and geometry needed for downstream work, and place the result in a format suited to geographic computation. That discipline matters for a world model such as E2 because finding and computing about real places depends on knowing what each feature represents, where it is, which source and version produced it, and what transformations occurred before it became searchable or comparable.
- •Normalize incoming GeoJSON layers representing physical features such as roads, buildings, parks, hydrants, service requests, or waterways before joining them to a broader geographic representation.
- •Convert exchange-oriented GeoJSON into a format better suited for spatial filtering, proximity analysis, aggregation, and repeated queries across cities or regions.
- •Use explicit reprojection and feature selection to prepare location data for computation about relationships between assets, addresses, transportation networks, infrastructure, and environmental features.
The EDK outcome
Before you start
A GDAL installation that includes the `ogrinfo` and `ogr2ogr` command-line utilities.
A representative GeoJSON file or an authorized, documented GeoJSON endpoint.
Authoritative knowledge of the source coordinate reference system, or a documented reason to supply one explicitly.
A clear destination format and understanding of whether the output is for analysis, storage, web delivery, or legacy interoperability.
A validation plan covering feature counts, geometry types, coordinate reference systems, extents, important attributes, and provenance or licensing metadata.
Learning objectives
Inspect a GeoJSON source before converting it.
Convert GeoJSON to GeoPackage, Shapefile, and other GDAL-supported vector formats.
Reproject data correctly and distinguish CRS assignment from CRS transformation.
Filter features and fields during conversion.
Create RFC 7946-oriented GeoJSON output.
Diagnose coordinate, schema, geometry, and reproducibility problems.
Automate conversion through the GDAL Python API when a command-line workflow is insufficient.
Verification
The output opens successfully with `ogrinfo` or another independent GIS client.
The output feature count matches expectations, allowing for intentional filters or an explicitly documented failed-feature policy.
The output extent is geographically plausible and comparable with the source after accounting for reprojection.
The output CRS is the intended CRS and coordinate values were transformed only when intended.
Geometry types, dimensionality, important properties, and field types meet the downstream contract.
If GeoJSON was round-tripped, representative extra members and coordinate precision were checked rather than assumed to be preserved.
The conversion command, GDAL version, source reference, and transformation choices are recorded for reproducibility.
Troubleshooting
The command says no driver is available: run `ogrinfo --formats` and confirm that both the GeoJSON driver and intended output driver are installed in the same GDAL environment.
The output is in the wrong place: inspect the source CRS with `ogrinfo`, verify the authoritative CRS declaration, and distinguish `-s_srs`, `-a_srs`, and `-t_srs`. Do not fix a misplaced dataset by assigning a new label unless the coordinates themselves are already correct.
The layer has unexpected fields: GeoJSON features can have varying property schemas. Inspect the fields produced by the driver and use `-select` or a controlled schema-mapping step if the destination contract is narrower.
The output has too many or too few features: check for `-where`, `-spat`, source paging behavior, layer selection, and warnings emitted during translation. Compare source and destination counts explicitly.
A Shapefile loses field names or types: this is usually a destination-format constraint. Use GeoPackage or another modern format when the application does not specifically require Shapefile.
The GeoJSON consumer rejects the result: inspect whether it expects RFC 7946, whether it supports the geometry types present, whether it requires a FeatureCollection, and whether it accepts the output’s dimensionality and property values.
Extra JSON members disappear: review native-data settings and test with a small round-trip sample. OGR fields and native JSON members are not interchangeable representations. (gdal.org)
A remote source is incomplete or unstable: save a controlled local copy when permitted, inspect server-side paging and limits, and record the retrieval date and request parameters. A direct URL conversion is not automatically a reproducible data-acquisition process.
Next steps
Use the converted dataset in a GeoPandas workflow for CRS-aware measurement, spatial joins, overlays, and summaries.
If the source is a live feature service, compare a one-time conversion with a documented WFS or OGC API Features ingestion workflow.
For repeated regional queries, consider a spatial database or indexed format rather than repeatedly parsing the same GeoJSON file.
Keep source provenance, transformation options, feature counts, and validation results alongside the output so later geographic computations can be traced back to the original data.
What GDAL and ogr2ogr actually do
GDAL is a library and toolset for raster and vector geospatial data. Its OGR vector model represents datasets, layers, features, fields, and geometries. The GeoJSON driver translates GeoJSON into that model and supports reading and writing GeoJSON from local text files, URLs, and text supplied directly to GDAL. A normal GeoJSON datasource is exposed as an OGR layer, commonly named `OGRGeoJSON`. (gdal.org)
`ogr2ogr` converts simple-features data between formats and can perform several operations during translation: spatial and attribute selection, field reduction, output CRS assignment, reprojection, geometry handling, appending, updating, or overwriting. The command is useful because conversion, transformation, and controlled extraction can happen in one reproducible operation. (gdal.org)
- •Input: a local `.geojson` or `.json` file, a supported URL, or another GDAL-readable vector source.
- •Output: a file-based format such as GeoPackage, Shapefile, FlatGeobuf, or GeoJSON, or a database destination supported by the installed drivers.
- •Transformation: reprojection, attribute filtering, spatial filtering, field selection, geometry-type control, and selected validity or collection operations.
- •Inspection: `ogrinfo` for metadata and sample features; `ogr2ogr` for translation and transformation.
Prerequisites and a safe first inspection
Install GDAL from a trusted operating-system package, Conda environment, or managed build. Confirm that the command-line utilities and the drivers for both the input and intended output are available before writing a conversion script. The exact installation command depends on the operating system and distribution, so there is no single universal installer command in this guide.
Before converting, decide what the output is for. A GeoPackage may be a good durable working file, while GeoJSON may be required for an API or browser application. Shapefile may be necessary for a legacy system, but it should be selected knowingly because its field and file-organization constraints can affect fidelity. GDAL’s vector-driver catalog documents whether installed drivers support creation and georeferencing. (gdal.org)
- •`gdalinfo --version`
- •`ogrinfo --formats`
- •`ogrinfo --help`
- •`ogr2ogr --help`
- •A representative GeoJSON file or an authorized, documented GeoJSON endpoint.
- •Authoritative information about the source CRS, or a documented reason to provide one explicitly.
- •A validation plan covering feature counts, geometry types, extents, CRS, important attributes, and provenance.
Step 1: inspect the GeoJSON source
Do not begin by guessing the layer name or coordinate system. Inspect the source with `ogrinfo` and record what GDAL actually sees:
The `-ro` flag opens the source read-only, `-al` requests all layers, and `-so` asks for a summary rather than printing every feature. Look for the layer name, geometry type, field names and types, feature count, extent, and spatial reference. A GeoJSON source is commonly represented as one OGR layer, but the layer name should still be taken from inspection rather than hard-coded.
- •`ogrinfo -ro -al -so input.geojson`
- •`ogrinfo -ro -al input.geojson | head -n 100`
- •Record whether the source declares a spatial reference or leaves it absent.
- •Inspect representative features if properties may vary between records.
- •Check whether the source contains collections, Z or M coordinates, null geometries, or unusually large attributes.
Step 2: convert GeoJSON to a practical working format
GeoPackage is often a useful general-purpose destination when you need a durable file, modern field handling, or the possibility of multiple layers. The basic conversion is:
If the source layer name is not the default, add the inspected name after the source dataset. Use `-overwrite` only when replacing an existing destination is intentional.
- •`ogr2ogr -f GPKG output.gpkg input.geojson`
- •`ogr2ogr -f GPKG output.gpkg input.geojson OGRGeoJSON`
- •`ogr2ogr -overwrite -f GPKG output.gpkg input.geojson`
- •`ogr2ogr -f "ESRI Shapefile" output_directory input.geojson`
Step 3: make coordinate reference systems explicit
Coordinate reference system errors are among the most damaging conversion failures because the output can be syntactically valid while being geographically misplaced or measured in inappropriate units. Keep these operations separate:
`-s_srs` supplies the source CRS when GDAL cannot determine it or authoritative source documentation says it is missing. `-t_srs` transforms coordinates into a target CRS. `-a_srs` assigns or overrides the declared CRS without transforming numeric coordinate values. Using `-a_srs` when a transformation is required can produce a dataset that is correctly labeled but incorrectly located.
- •Transform coordinates into a target CRS: `ogr2ogr -f GPKG projected.gpkg input.geojson -t_srs EPSG:3857`
- •Supply a known but undeclared source CRS and transform: `ogr2ogr -f GPKG projected.gpkg input.geojson -s_srs EPSG:4326 -t_srs EPSG:26918`
- •Assign a declaration without moving coordinates only when that is genuinely the intended operation: `ogr2ogr -f GPKG labeled.gpkg input.geojson -a_srs EPSG:4326`
Step 4: write standards-oriented GeoJSON
If the objective is a web or interchange GeoJSON file rather than a database-oriented working copy, use the GeoJSON driver’s RFC 7946 layer creation option:
GDAL documents several differences between its historical GeoJSON output and RFC 7946 output. RFC 7946 output uses geographic coordinates over the WGS 84 ellipsoid, applies polygon ring-orientation rules, uses defined bounding-box ordering, and defaults to seven decimal places of coordinate precision. GDAL can reproject to the required geographic coordinate system during writing when the output layer is configured for RFC 7946. (gdal.org)
- •`ogr2ogr -f GeoJSON output.geojson input.gpkg -lco RFC7946=YES`
- •Use `-lco COORDINATE_PRECISION=7` or another explicit value when coordinate precision is part of the output contract.
- •Test native-data and extra-member behavior if the original GeoJSON contains custom members outside ordinary feature properties.
Step 5: filter, reduce, and automate the output
GDAL can reduce a dataset during conversion rather than requiring a separate preprocessing step. A bounding-box subset can be created with `-spat`, an attribute subset with `-where`, and a narrower schema with `-select`.
The source driver and SQL or attribute model determine which expressions and field behaviors are available. Inspect the source schema first and verify the destination schema afterward. GeoJSON features can contain varying property sets; the resulting OGR schema may therefore contain a union of fields across features.
- •`ogr2ogr -f GPKG subset.gpkg input.geojson -spat -74.10 40.65 -73.90 40.85`
- •`ogr2ogr -f GPKG selected.gpkg input.geojson -where "status = 'active'"`
- •`ogr2ogr -f GPKG reduced.gpkg input.geojson -select id,name,status`
- •Python entry point: `from osgeo import gdal` followed by `gdal.VectorTranslate(...)`.
Step 6: validate the result before geographic computation
Inspect the output with the same discipline used for the input:
Compare source and destination feature counts when no filter was intended. Check that the geometry type is expected, the extent is plausible, the CRS is correct, and important fields retained their values and types.
- •`ogrinfo -ro -al -so output.gpkg`
- •`ogrinfo -ro -al output.gpkg | head -n 100`
- •Compare feature counts, extents, geometry types, CRS declarations, and selected attribute values.
- •Run an independent check for empty or invalid geometries when the dataset will support measurement or spatial joins.
Workflow
1. Inspect the source
Run `ogrinfo -ro -al -so input.geojson`. Record the layer name, geometry type, feature count, extent, fields, and spatial reference before changing anything.
ogrinfo -ro -al -so input.geojson2. Convert to a working format
Use GeoPackage for a durable, general-purpose vector copy. Add `-overwrite` only when replacing an output is intentional.
ogr2ogr -f GPKG output.gpkg input.geojson3. Transform the coordinate reference system
Use `-t_srs` when coordinates must be transformed. Use `-s_srs` only when the source CRS needs to be supplied explicitly, and do not substitute `-a_srs` for a transformation.
ogr2ogr -f GPKG output_projected.gpkg input.geojson -t_srs EPSG:38574. Filter features or fields
Use `-spat` for a bounding-box subset, `-where` for an attribute predicate, and `-select` to reduce the output field list. Confirm source field names and types first.
ogr2ogr -f GPKG subset.gpkg input.geojson -spat -74.10 40.65 -73.90 40.85 -select id,name,status5. Write RFC 7946 GeoJSON
When the destination is GeoJSON and standards-oriented output is required, set the GeoJSON layer creation option.
ogr2ogr -f GeoJSON output.geojson input.gpkg -lco RFC7946=YES6. Validate independently
Inspect the output with `ogrinfo`, compare counts and extents, verify the CRS, and test representative geometries and attributes. For production, record the GDAL version, command or options, source identifier, acquisition time, and output checksum.
ogrinfo -ro -al -so output.gpkgQuestions teams ask
Should I use `ogr2ogr` or `gdal vector convert`?
Use `ogr2ogr` when you need the broadly documented and widely recognized vector-translation command, especially in existing scripts or mixed-version environments. GDAL also documents `gdal vector convert` as a newer command for format conversion, but the stable documentation describes the consolidated `gdal` interface as provisional until it is formally frozen. Check the GDAL version installed in the deployment and test the exact options you intend to use. (gdal.org)
What is the difference between `-a_srs` and `-t_srs`?
`-a_srs` assigns or overrides the declared spatial reference without transforming coordinate values. `-t_srs` transforms coordinates into the target spatial reference. If source coordinates are already numerically correct but lack a declaration, assignment may be appropriate. If coordinates must move from one CRS to another, supply the source definition when necessary and use `-t_srs` for the transformation.
Why did my GeoJSON output move after conversion?
Common causes include an incorrect or missing source CRS, an unintended `-a_srs` assignment, an intentional `-t_srs` transformation that was not expected, or confusion about coordinate order. Inspect both datasets with `ogrinfo`, compare extents, and verify the source CRS from authoritative producer documentation rather than guessing from coordinate values.
Can GDAL preserve every property in the original GeoJSON?
Not automatically in every situation. Ordinary OGR fields represent many GeoJSON properties, but extra members at the FeatureCollection, Feature, or geometry level may require native-data handling for round-tripping. GDAL documents `NATIVE_DATA`, native media types, and the `-noNativeData` switch for controlling this behavior. Test representative data if those extra members are important. (gdal.org)
When should I convert GeoJSON to GeoPackage instead of Shapefile?
GeoPackage is generally preferable when you need modern field types, multiple layers, fewer sidecar files, or a durable working dataset. Shapefile remains useful when a particular legacy application requires it, but its constraints should be treated as an interoperability tradeoff rather than an ideal internal data model.
Keep exploring
analyze spatial data with geopandas
After converting GeoJSON, GeoPandas provides a practical workflow for inspecting CRS, measuring, joining, filtering, and summarizing the resulting geographic features.
consume wfs in python
When GeoJSON originates from a live feature service, this guide helps distinguish downloading a static representation from querying an authoritative web feature source.
Sources
GDAL GeoJSON driver documentation
Authoritative documentation for GeoJSON input and output behavior, layer handling, schema detection, RFC 7946 writing, remote sources, virtual file systems, and native-data preservation.
Open sourceGDAL ogr2ogr documentation
Authoritative reference for vector translation syntax, reprojection, filtering, field selection, spatial selection, output formats, and conversion examples.
Open sourceGDAL RFC 65: RFC 7946 GeoJSON
GDAL implementation documentation for RFC 7946 GeoJSON output and its differences from legacy GeoJSON behavior.
Open sourceGDAL Python utilities API
Authoritative reference for using `gdal.VectorTranslate` and `VectorTranslateOptions` from Python.
Open sourceGDAL vector-driver catalog
Authoritative list of vector drivers and their documented read, write, creation, and georeferencing support.
Open source