Free and Open Source GIS Tools for Format Conversion and Analysis

The problem with most “free GIS tools” roundup lists is that they treat GDAL, QGIS, GRASS, and PostGIS as competing products when they’re actually layers of the same stack. GDAL underpins QGIS. QGIS calls GRASS as a processing backend. PostGIS sits behind both for production data. Choosing between them isn’t “which is best” — it’s “which layer do I need to interact with directly.”

This is a functional comparison: what each tool does well, where it breaks down, and which one to reach for when you receive a shapefile, a GeoJSON, or a KML and need it in something your software actually reads.

GDAL/OGR: The Conversion Engine

GDAL (Geospatial Data Abstraction Library) is the format translation layer everything else uses. QGIS uses it. PostGIS uses it. ArcGIS Pro uses a licensed build of it. GDAL handles raster; its vector companion OGR handles the formats most conversion work involves.

The library supports over 250 raster formats and more than 80 vector drivers. When you export from QGIS to Shapefile, OGR does the actual conversion. When you import a GeoTIFF into any desktop GIS, GDAL decodes it.

For format conversion, reaching for ogr2ogr directly is often faster than opening a GUI:

# GeoJSON to Shapefile
ogr2ogr -f "ESRI Shapefile" output.shp input.geojson

# GeoJSON to GeoPackage
ogr2ogr -f GPKG output.gpkg input.geojson

# Reproject on the fly (WGS84 to Web Mercator)
ogr2ogr -f "ESRI Shapefile" output.shp input.shp -t_srs EPSG:3857

# Filter by attribute during conversion
ogr2ogr -f "ESRI Shapefile" output.shp input.geojson -where "region='northwest'"

# Clip to bounding box during export
ogr2ogr -f "ESRI Shapefile" output.shp input.geojson -clipsrc -122.5 37.7 -122.3 37.9

ogr2ogr handles conversion, reprojection, attribute filtering, and spatial clipping in a single pass. For scripted pipelines — nightly data pulls, CI/CD geospatial validation, batch processing of incoming survey files — this is the right abstraction.

Known footguns with Shapefile output:

• Field name truncation: Shapefile limits field names to 10 characters. OGR truncates silently. If two attributes truncate to the same 10-char prefix, one is silently dropped or renamed with a numeric suffix. Verify with ogrinfo -al -so output.shp.
• String length cap: Shapefile attribute strings max at 254 characters. Longer values are silently truncated on write.
• Mixed geometry types: Shapefile requires a single geometry type per file. OGR writes whatever geometry it encounters. Pass -nlt POLYGON or -nlt MULTIPOLYGON to enforce the type and catch mismatches early.
• Date field handling: OGR maps GeoJSON string fields that look like ISO dates to Shapefile Date type, which drops time components.

The silent data loss that happens during GeoJSON-to-Shapefile conversion is directly caused by these Shapefile spec limitations — GDAL can’t work around a 10-char field name limit, only warn about it if you ask.

GDAL installs via conda install -c conda-forge gdal, brew install gdal on macOS, or the OSGeo4W installer on Windows. The Python bindings (from osgeo import ogr, osr) expose the same capabilities in scripts.

QGIS: Desktop GIS for Everything ogr2ogr Can’t Do

QGIS is the full-featured desktop GIS in the FOSS stack — the only open-source option that competes with ArcGIS Pro in terms of UI surface area. It accesses over 1,000 processing algorithms via GDAL, GRASS GIS, SAGA, and native QGIS providers, all through a unified Processing Toolbox.

For format conversion work specifically, QGIS adds two things command-line GDAL doesn’t:

Visual verification before export. You can open both source and converted files side by side to catch geometry drops, CRS mismatches, or attribute truncation before it reaches downstream systems. The preflight validation checks that matter most — null geometry, self-intersecting rings, mixed geometry types — are visible in QGIS before they become someone else’s problem.

Project-level DXF export. QGIS has a separate DXF export path under Project → Export → Export Project to DXF that respects layer visibility and symbology. The common mistake is using “Save Features As” on individual layers, which silently drops polygon holes and self-intersections. If your DXF output ends up in Rhino or AutoCAD, the difference matters.

QGIS runs on Windows, macOS, and Linux. The long-term release (LTR) version is what to install for production workflows. The OSGeo4W installer on Windows bundles GDAL, GRASS, and SAGA alongside QGIS as a coordinated install, which avoids the path conflicts that come from installing each component separately.

One caveat: QGIS’s processing algorithms vary in quality. Native QGIS algorithms and GDAL-backed ones are reliable. SAGA algorithms work but occasionally produce unexpected results on edge case geometry. GRASS algorithms are solid but require GRASS to be installed and configured correctly. When something breaks in the Processing Toolbox, the first diagnostic is checking which provider the algorithm uses.

GRASS GIS: Analysis Depth at the Cost of Ergonomics

GRASS GIS (Geographic Resources Analysis Support System) started at the US Army Corps of Engineers in the early 1980s and was released as open source in 1999. It ships over 500 processing modules, more than any other FOSS GIS tool, concentrated in raster analysis, terrain modeling, hydrology, image processing, and network analysis.

GRASS organizes data in a location/mapset filesystem structure — data does not live in ordinary directories, it lives in a GRASS database with a defined CRS per location. This surprises every new user and requires a few sessions to internalize. The payoff is a unified coordinate reference system enforced across all data in a project, so CRS mismatches fail loudly rather than silently producing shifted output.

Where GRASS wins over QGIS Processing native algorithms:

• Hydrology: r.watershed, r.stream.extract, r.topidx for full basin extraction with flow accumulation — faster and more numerically stable than equivalent SAGA algorithms on large DEMs
• Solar radiation: r.sun for position-accurate solar irradiance simulation, widely used in renewable energy siting and urban solar access studies
• Temporal series: the TGRASS temporal framework handles time-series raster stacks natively — NDVI change detection, climate model outputs, multi-date Sentinel imagery
• Network analysis: v.net.path, v.net.salesman for routing on linear networks with real topological consistency

For most teams, the right way to use GRASS is as a QGIS Processing backend rather than standalone. If GRASS is installed and the QGIS GRASS provider is configured, GRASS algorithms appear in the QGIS Processing Toolbox alongside native algorithms — you get GRASS’s analytical depth without the GRASS GUI’s learning curve.

The standalone GRASS GUI makes sense for workflows that are primarily raster-based and large-scale, or when you need TGRASS temporal analysis. For vector-heavy workflows with occasional raster analysis, QGIS + GRASS provider is the right combination.

PostGIS: When Data Doesn’t Fit on a Workstation

PostGIS extends PostgreSQL with spatial data types (geometry, geography), spatial indexes (GiST indexes on geometry columns), and a function library of hundreds of spatial operations. It is the right tool when:

• Dataset size exceeds what processes comfortably in QGIS (rough threshold: above ~1M features for interactive workflows, or anything above ~10GB)
• Multiple users need concurrent read/write access to the same geometry
• You need transactional guarantees on geometry edits
• Spatial joins need to run inside the database rather than pulling data into a client first

Representative operations that PostGIS handles well:

-- Which buildings are within 500 metres of a flood zone?
SELECT b.id, b.address
FROM buildings b
JOIN flood_zones fz ON ST_DWithin(b.geom, fz.geom, 500)
WHERE fz.risk_level = 'high';

-- Area in square kilometres (geography type handles ellipsoidal calculation)
SELECT id, ST_Area(geom::geography) / 1e6 AS area_km2
FROM parcels;

-- Dissolve polygons by attribute
SELECT region, ST_Union(geom) AS geom
FROM parcels
GROUP BY region;

-- Validate and fix geometry in-place
UPDATE parcels
SET geom = ST_MakeValid(geom)
WHERE NOT ST_IsValid(geom);

PostGIS connects to QGIS directly via the PostgreSQL layer provider — you can edit features in QGIS and commit them to the database with full undo history. GDAL loads data into PostGIS via ogr2ogr in a single command:

ogr2ogr -f PostgreSQL PG:"host=localhost dbname=geostore user=gis" \
  input.geojson -nln target_table -lco GEOMETRY_NAME=geom

The -lco GEOMETRY_NAME=geom option sets the geometry column name to geom rather than the ogr2ogr default wkb_geometry, which keeps PostGIS queries cleaner.

If you’re choosing between GeoParquet, GeoPackage, and Shapefile for file-based storage, PostGIS sits above all of them as the query layer for team workflows — you load from file formats into PostGIS for analysis and export back out for delivery.

Legacy Special-Purpose Tools: DIVA-GIS and What Replaced It

DIVA-GIS was a Windows-only free GIS tool focused on species distribution modeling and biodiversity analysis. It was widely used in ecology research from the early 2000s through the mid-2010s. The diva-gis.org site is no longer reliably accessible, and active development has stopped.

The functionality DIVA-GIS provided has moved into maintained tools:

If your workflow references DIVA-GIS tutorials or documentation, the underlying operations translate directly to QGIS with a GRASS raster analysis backend. The GBIF occurrence downloader plugin in QGIS gives direct access to biodiversity data in the same pipeline where you’d do the analysis.

Web-Based Conversion: When You Don’t Need the Full Stack

Command-line GDAL and QGIS handle everything in the FOSS stack. Both require installation, configuration, and familiarity with the toolchain. For a one-off conversion — someone on your team receives a GeoJSON and needs a Shapefile for a client requiring ArcGIS compatibility — a web tool removes the friction.

GeoConvert handles GeoJSON to ESRI Shapefile in the browser, GDAL-backed: CRS preservation, RFC 7946-compliant attribute mapping, geometry validation and repair. Output is a .zip containing .shp, .shx, .dbf, and .prj. No installation, no account needed for small files.

The tradeoff applies to any web conversion tool: it works for the stated input/output pair. For complex format pipelines, multi-format batch processing, or anything requiring custom transformation logic, ogr2ogr is the right level.

Which Tool for Which Job

The stack is additive. Most production workflows touch all four layers: GDAL for ingestion and file conversion, PostGIS for storage and spatial query, QGIS for editing and visual verification, GRASS for analysis that QGIS native algorithms don’t cover.

Understanding when GeoJSON is the right format versus when to convert it for working storage matters for how you use these tools together — GeoJSON is frequently the input to these pipelines, rarely the format that stays in the database through the analysis process.