Convert GeoJSON with GDAL: production guide for reliable geospatial data pipelines
A production-oriented guide to converting GeoJSON with GDAL. It covers environment checks, source inspection, format conversion, reprojection, RFC 7946 output, filtering, precision, validation, repeatable automation, and the tradeoffs of using GeoJSON as an interchange format rather than an analytical store.
GeoJSON is convenient because it is readable, widely supported, and easy to move between web maps, APIs, desktop GIS applications, and scripts. In production, however, conversion is not simply a matter of changing a file extension. You need to know what geometry and attributes are present, which coordinate reference system the source uses, how the destination format represents fields, whether the output must follow RFC 7946, and how to verify that the converted dataset still represents the same physical features. GDAL provides the command-line utilities and format drivers needed for this workflow. The central command is ogr2ogr, which converts vector data between formats. ogrinfo is the inspection tool: use it before and after conversion to examine layers, geometry types, coordinate systems, fields, extents, and feature counts. The GeoJSON driver supports reading and writing GeoJSON and can work with local files, URLs, and GDAL virtual file-system paths. (gdal.org)
How EDK fits
For: GIS developers, data engineers, mapping teams, and analysts who need a repeatable way to convert GeoJSON into GeoPackage, Shapefile, FlatGeobuf, another GeoJSON file, or a downstream geospatial database.
Converting GeoJSON is a concrete example of the boundary between a file format and a usable world model. GeoJSON can carry points, lines, polygons, properties, and coordinate information, but conversion determines how those features become available for search, comparison, measurement, filtering, and geographic computation. A reliable GDAL workflow preserves the link between a record and the physical feature it represents while making format, coordinate reference system, schema, precision, and provenance explicit. That connection matters when many kinds of physical data must be brought together: roads, buildings, waterways, parks, service requests, infrastructure, permits, or environmental observations. A converted dataset can become one input to a larger geographic system, where features are ranked by proximity, aggregated by region, compared across time, or related to other layers. GDAL does not itself provide a complete world model, place search system, routing service, or universal data catalog; it is a practical interoperability and transformation layer. Its value here is making external geographic data more consistent and computable before it is combined with other representations of Earth.
- •Normalize GeoJSON layers representing roads, buildings, waterways, public assets, or environmental features into a common CRS and output format before spatial joins, proximity analysis, regional aggregation, or change comparison.
- •Convert incoming location datasets into a stable interchange or analytical format, then validate geometry, schema, extents, and feature counts before incorporating them into a searchable representation of physical places.
- •Use bounded ogr2ogr conversions and explicit layer options as a repeatable preprocessing step for geographic data that will later be filtered, ranked, measured, or related to nearby infrastructure and services.
The EDK outcome
Before you start
Install GDAL and confirm that ogr2ogr and ogrinfo are available on the command line.
Obtain a GeoJSON source and document its origin, license, acquisition date, and expected layer contents.
Identify the source CRS and target CRS; do not guess a missing CRS from coordinate values alone.
Decide whether the destination is for interchange, browser delivery, desktop GIS, local analysis, or database loading.
Create a test workspace that preserves the original input and separates temporary, final, and validation outputs.
Learning objectives
Inspect GeoJSON structure before conversion.
Convert GeoJSON into common vector formats with ogr2ogr.
Distinguish CRS assignment from coordinate transformation.
Create RFC 7946-compatible GeoJSON output when required.
Filter features and fields deliberately.
Validate converted datasets and automate repeatable production jobs.
Choose an output format based on geographic workload rather than file extension alone.
Verification
The output opens successfully with ogrinfo in read-only mode.
The expected layer exists and has the intended geometry type or documented mixed-geometry behavior.
The feature count is equal to or intentionally different from the source for a documented reason.
The output extent is plausible and falls within the expected geographic area.
The output CRS is the intended CRS, and coordinates were transformed only when required.
Required attributes are present, with acceptable field names and types.
For RFC 7946 output, coordinates and GeoJSON behavior meet the consuming system’s requirements.
A representative sample has been checked manually or through automated assertions.
The output can be reproduced from the documented source, command, GDAL version, and options.
Troubleshooting
ogr2ogr reports that no suitable driver was found: run ogrinfo --formats or ogr2ogr --formats, confirm the input extension and content, and specify the driver with -if GeoJSON when supported by the installed GDAL version. The GeoJSON driver is built in by default in current GDAL documentation. (gdal.org)
The map appears in the wrong place: check whether the source CRS was missing or incorrectly assigned. Do not fix this by trying arbitrary CRS codes. Establish the source CRS, use -a_srs for metadata assignment, or use -s_srs and -t_srs for a real transformation.
The output is empty: inspect the source without filters, then remove -where, -spat, -sql, or an overly restrictive layer name one at a time. Confirm that the attribute names and values match the source schema.
Fields are missing or altered: compare ogrinfo summaries, use -select for deliberate field control, and choose a destination format that supports the required types and names.
The output GeoJSON is rejected by a consumer: try -lco RFC7946=YES, inspect the resulting CRS and geometry, and check whether the consumer supports the geometry types and dimensions being written.
A conversion is slow or consumes too much memory: avoid listing all features with ogrinfo, process a bounded subset first, choose a more suitable destination format, and test whether the source or destination driver has a more efficient access pattern. (gdal.org)
Remote input fails intermittently: download and checksum the source first when reproducibility matters, or validate the URL with ogrinfo before running the conversion job. Network access, authentication, server paging, and virtual file-system behavior may differ between environments. (gdal.org)
Polygon results look different after RFC 7946 conversion: inspect whether reprojection, antimeridian splitting, ring orientation, or coordinate precision changed the representation. Compare the geographic footprint and intended topology rather than only the raw coordinate text. (gdal.org)
Next steps
Add automated checks for feature counts, bounding boxes, CRS, required fields, and null rates.
Store conversion manifests and validation reports next to published datasets.
Use GeoPandas or a spatial database for downstream joins, measurements, and repeated geographic computation when the converted file is no longer the right analytical boundary.
Publish source attribution, licensing, acquisition time, and transformation details with every derived dataset.
Link converted layers to the physical-world entities they represent—such as roads, buildings, waterways, public assets, or service locations—without treating format conversion as proof of feature accuracy or freshness.
What this workflow does—and what it does not
GDAL’s vector utilities operate on datasets exposed through OGR drivers. The GeoJSON driver maps GeoJSON data into OGR datasources, layers, features, geometries, and fields. A GeoJSON FeatureCollection is normally exposed as one layer, and the driver can read or write local files as well as selected remote or virtual-file inputs. (gdal.org)
This guide focuses on controlled conversion rather than blind file rewriting. The objective is to produce an output whose coordinate system, geometry behavior, attributes, precision, and format are understood. GDAL can transform coordinates, filter features, select fields, change geometry types, and write to many vector formats, but it cannot determine whether a source is authoritative, whether an address is current, whether a road is physically open, or whether two records refer to the same real-world feature.
- •Use GeoJSON when interoperability, human readability, or browser delivery is important.
- •Use a more structured or indexed destination when you need repeated spatial queries, transactional updates, large-scale analytics, or compact storage.
- •Do not infer a missing CRS from the country, city, or coordinate magnitude alone. If the source does not document its CRS, stop and resolve that uncertainty before transforming coordinates.
Prerequisites and a controlled setup
Install GDAL from a trusted operating-system package, a managed environment, or an official distribution appropriate to your platform. Confirm that the utilities are available and record the version used by the conversion job. GDAL behavior and available options can vary by release, so a production pipeline should pin or document its runtime rather than relying on an unspecified workstation installation.
Create a working directory with separate locations for source files, intermediate outputs, final outputs, logs, and validation reports. Never overwrite the only copy of the source during development. For repeatability, place the exact command in a shell script or job definition and write stdout and stderr to a log.
- •A GDAL installation that provides ogr2ogr and ogrinfo.
- •A source GeoJSON file or documented URL.
- •The source CRS, if known, and the target CRS required by the destination system.
- •A clear decision about whether all source fields must be preserved.
- •A small test subset or representative sample for rapid iteration.
- •Enough disk space for both source and destination datasets.
Step 1: inspect the source before conversion
Start with a read-only summary. The -ro flag prevents accidental updates, while -so reports summary information instead of every feature. The -al option lists all layers; for ordinary GeoJSON, the driver generally exposes a single layer. (gdal.org)
- •Command: ogrinfo -ro -al -so input.geojson
- •Command: ogrinfo -ro -json -so input.geojson > input-summary.json
- •Command: ogrinfo -ro -al -so -geom SUMMARY input.geojson
- •Command: ogrinfo -ro -al -so -where "status = 'active'" input.geojson
- •Command: ogrinfo -ro -al -so -spat -122.6 37.7 -122.3 37.9 input.geojson
Step 2: perform a basic format conversion
The simplest conversion names the output format with -f, followed by the destination dataset and source dataset. This example writes a GeoPackage, a commonly useful single-file vector container for local GIS workflows and exchange between desktop and programmatic tools.
- •Command: ogr2ogr -f GPKG output.gpkg input.geojson
- •Command: ogr2ogr -f GPKG output.gpkg input.geojson -nln features
- •Command: ogr2ogr -f FlatGeobuf output.fgb input.geojson
- •Command: ogr2ogr -f "ESRI Shapefile" output.shp input.geojson
Step 3: make coordinate reference systems explicit
Coordinate reference systems are one of the most important production concerns. Use -a_srs when the source coordinates are already in a known CRS but the dataset lacks or has incorrect CRS metadata. This assigns metadata; it does not move the coordinates. Use -t_srs when coordinates must be transformed into another CRS. GDAL then performs a reprojection during conversion. The two operations should not be substituted for one another.
- •Assign a known source CRS without changing numeric coordinates: ogr2ogr -f GPKG output.gpkg input.geojson -a_srs EPSG:4326
- •Transform coordinates to Web Mercator: ogr2ogr -f GPKG output.gpkg input.geojson -s_srs EPSG:4326 -t_srs EPSG:3857
- •Transform to a projected CRS selected for local measurement: ogr2ogr -f GPKG output.gpkg input.geojson -t_srs EPSG:26910
- •Inspect the result: ogrinfo -ro -al -so output.gpkg
Step 4: produce standards-oriented GeoJSON
When the destination must be GeoJSON for web or standards-based interchange, use the GeoJSON driver’s RFC7946 layer creation option. GDAL documents RFC 7946 output as using geographic WGS 84 coordinates, with polygon orientation and antimeridian behavior handled according to that standard. The driver also uses a default coordinate precision associated with RFC 7946 output, which can be overridden when appropriate. (gdal.org)
- •Command: ogr2ogr -f GeoJSON output-rfc7946.geojson input.gpkg -lco RFC7946=YES
- •Command with explicit precision: ogr2ogr -f GeoJSON output-rfc7946.geojson input.gpkg -lco RFC7946=YES -lco COORDINATE_PRECISION=7
- •Write bounding boxes when consumers need them: ogr2ogr -f GeoJSON output.geojson input.gpkg -lco RFC7946=YES -lco WRITE_BBOX=YES
- •Select the output layer name: ogr2ogr -f GeoJSON output.geojson input.gpkg -nln places -lco RFC7946=YES
Step 5: control fields, filters, and geometry
Production conversions often need to reduce the output rather than copy every source field and feature. Use -select to choose fields, -where for attribute filtering, -spat for a bounding-box filter, and -sql when a more expressive query is appropriate. The exact query behavior depends on the source driver and selected dialect, so validate the result instead of assuming every SQL function is portable.
- •Select fields: ogr2ogr -f GPKG output.gpkg input.geojson -select id,name,status
- •Filter records: ogr2ogr -f GPKG output.gpkg input.geojson -where "status = 'active'"
- •Limit by bounding box: ogr2ogr -f GPKG output.gpkg input.geojson -spat -122.6 37.7 -122.3 37.9
- •Request a geometry type: ogr2ogr -f GPKG output.gpkg input.geojson -nlt PROMOTE_TO_MULTI
- •Overwrite a deliberately replaceable output: ogr2ogr -overwrite -f GPKG output.gpkg input.geojson
Step 6: validate the converted dataset
Validation should be a separate command, not an assumption that a successful process exit means the output is correct. Compare the source and destination summaries. Check feature count, extent, geometry type, CRS, fields, null behavior, and a few representative features. For a reprojection, verify that the output CRS changed as intended and that the geographic footprint remains plausible.
- •Command: ogrinfo -ro -al -so output.gpkg
- •Command: ogrinfo -ro -json -so output.gpkg > output-summary.json
- •Command: ogrinfo -ro -al -features -limit 3 output.gpkg
- •Command: ogrinfo -ro -al -geom SUMMARY output-rfc7946.geojson
- •For a bounded conversion, independently confirm that the output extent falls within the requested area.
- •For a schema-reducing conversion, confirm that fields intentionally removed are absent and required fields remain.
Step 7: automate the conversion as a production job
A durable job should make inputs, outputs, CRS assumptions, driver options, and validation checks explicit. Fail the job when the source is missing, the command returns a nonzero status, the output has zero features unexpectedly, the output CRS is wrong, or the output file is implausibly small. Keep the original source and write a manifest containing the source identifier, command, GDAL version, target format, target CRS, feature count, extent, and timestamp.
For large sources, test memory and runtime characteristics with a representative sample before processing the full dataset. Avoid enabling feature-listing modes on very large collections merely to inspect them: the ogrinfo documentation warns that building complete feature output can exhaust memory. (gdal.org)
- •Use temporary output paths and rename only after validation succeeds.
- •Make overwrite behavior explicit; do not silently replace a trusted dataset.
- •Record whether RFC7946, precision, field selection, filters, or geometry promotion were used.
- •Run a post-conversion summary and retain the report with the output artifact.
- •Keep source licensing and attribution metadata with the pipeline documentation.
Workflow
1. Check the GDAL installation
Confirm the utilities and record the runtime version before creating production outputs.
ogr2ogr --version
ogrinfo --version2. Inspect the input
Use read-only summary output to understand the source layer, CRS, geometry, fields, feature count, and extent.
ogrinfo -ro -al -so input.geojson
ogrinfo -ro -json -so input.geojson > input-summary.json3. Convert to a destination format
Start with a basic conversion, then add a layer name, field selection, filter, or geometry option only when the requirement is explicit.
ogr2ogr -f GPKG output.gpkg input.geojson -nln features
ogr2ogr -f FlatGeobuf output.fgb input.geojson4. Transform or assign the CRS
Use -a_srs only to assign known metadata. Use -t_srs to transform coordinates into the target CRS.
ogr2ogr -f GPKG output.gpkg input.geojson -a_srs EPSG:4326
ogr2ogr -f GPKG output.gpkg input.geojson -s_srs EPSG:4326 -t_srs EPSG:38575. Create RFC 7946 GeoJSON
Use the GeoJSON driver and RFC7946 layer creation option when the consuming system requires the RFC 7946 model.
ogr2ogr -f GeoJSON output.geojson input.gpkg -lco RFC7946=YES6. Validate the result
Inspect the destination independently and compare its summary with the source. Check counts, extents, CRS, fields, geometry types, and representative features.
ogrinfo -ro -al -so output.gpkg
ogrinfo -ro -al -features -limit 3 output.gpkg7. Automate and retain provenance
Run conversion into a temporary path, validate it, then publish it. Retain the command, GDAL version, source identifier, target CRS, options, validation report, and timestamp.
set -e
ogr2ogr -overwrite -f GPKG output.tmp.gpkg input.geojson
ogrinfo -ro -al -so output.tmp.gpkg > output-summary.txt
mv output.tmp.gpkg output.gpkgQuestions teams ask
What is the difference between -a_srs and -t_srs in ogr2ogr?
-a_srs assigns a spatial reference to coordinates that are already expressed in that CRS; it does not transform the numeric coordinate values. -t_srs transforms coordinates into the target CRS during conversion. If the source CRS is known but missing, use -a_srs. If the coordinates need to be reprojected, use -t_srs and, when necessary, specify the source with -s_srs.
How do I convert a Shapefile or GeoPackage to RFC 7946 GeoJSON?
Use ogr2ogr with the GeoJSON output driver and the RFC7946 layer creation option: ogr2ogr -f GeoJSON output.geojson input.gpkg -lco RFC7946=YES. GDAL’s documentation states that RFC 7946 output uses geographic WGS 84 coordinates and applies the relevant GeoJSON conventions. Validate the result with ogrinfo afterward. (gdal.org)
Why did my output lose fields or change field types?
OGR converts source fields into the capabilities of the destination driver. Some formats impose restrictions on field names, types, list values, nulls, or widths. Inspect the source and destination schemas with ogrinfo, use -select to control the intended fields, and choose a destination format whose schema can represent the source requirements.
Can GDAL convert a remote GeoJSON URL?
The GeoJSON driver documents URLs as supported datasource inputs, and GDAL also provides virtual file-system handlers for network-hosted and archived resources. Whether a particular URL works depends on the server response, authentication, format, paging behavior, and driver detection. Test the URL with ogrinfo first, then use ogr2ogr only after the source can be inspected reliably. (gdal.org)
Should I use GeoJSON as my production storage format?
It depends on the workload. GeoJSON is a strong choice for interchange, browser delivery, small-to-moderate extracts, and human-readable artifacts. For repeated spatial queries, large collections, concurrent access, transactional updates, or analytical pipelines, evaluate GeoPackage, FlatGeobuf, or a spatial database instead. The correct choice depends on data volume, query patterns, deployment, and interoperability requirements.
Keep exploring
analyze spatial data with geopandas production guide
After conversion, GeoPandas provides a practical workflow for checking CRS, performing spatial joins, measuring geometry, and validating analytical results.
consume wfs in python production guide
WFS workflows often produce feature data that must be inspected, bounded, transformed, and converted before it enters a local or analytical pipeline.
build a web map with maplibre production guide
Converted GeoJSON is commonly used as an input overlay for browser maps, where coordinate order, source size, geometry, and provider behavior affect rendering.
Sources
GDAL GeoJSON driver documentation
Authoritative documentation for GeoJSON read/write behavior, datasource and layer handling, CRS behavior, RFC 7946 output, precision, configuration options, and examples.
Open sourceGDAL ogr2ogr documentation
Authoritative reference for vector conversion syntax, reprojection, filtering, field selection, geometry options, overwrite behavior, and output drivers.
Open sourceGDAL ogrinfo documentation
Authoritative reference for inspecting vector datasets, summaries, schemas, extents, features, spatial filters, and JSON output.
Open sourceGDAL RFC 65: RFC 7946 GeoJSON
GDAL’s implementation documentation for RFC 7946 GeoJSON output, including WGS 84 coordinates, polygon winding, antimeridian handling, and precision.
Open sourceGDAL virtual file systems documentation
Authoritative documentation for reading network-hosted and archived data through GDAL virtual paths such as /vsicurl/ and /vsizip/.
Open source