Shapefile Format: The Complete Definitive Guide

Someone sent you "a shapefile" and it is a folder of five files with the same name. Or a layer you exported from QGIS shows up in the middle of the Atlantic. Or a colleague opened your attribute table and every accent has turned into é. This guide is for the person who has to deal with that today, and for the developer who has been told to "just support Shapefiles" and wants to know what they are signing up for. The short version first: a Shapefile is ESRI's 1990s vector format — a .shp of geometry, a .dbf of attributes, a .shx index and, in practice, a .prj for the coordinate system, all sharing one base name.

Everything factual on this page was tested, not copied. We built Shapefiles from GeoJSON with GDAL 3.13.3 "Iowa City", deleted their sidecar files one at a time, read the .dbf bytes with a hex reader, forced encoding mistakes on purpose and quoted the exact errors GDAL prints. Where a claim comes from the ESRI Shapefile Technical Description (July 1998) rather than from our terminal, we say so. Everything here was verified on 10 September 2026.

One thing up front: the Shapefile is a 1990s format that is still the most widely accepted way to exchange vector data, and its specification is frozen, so none of its problems will be fixed. This guide is not here to tell you to stop using it. It is here so you know exactly which of your data it will destroy, and how to get the data out intact.

What is a Shapefile? The .shp, .shx, .dbf and .prj files

A Shapefile is not a file. It is a set of files that share a base name and differ by extension, and a reader needs several of them at once. The most common "broken" Shapefile is one file that was sent without the others.

• .shp — mandatory. The geometry. Every record is a shape type code followed by coordinates. There is no attribute data here and no coordinate system.
• .shx — mandatory. A fixed-width index: for each record, its byte offset into the .shp, so a reader can jump straight to a feature.
• .dbf — mandatory. The attribute table, in dBASE format. Record n in the .dbf belongs to shape n in the .shp; nothing but position links them.
• .prj — mandatory in practice. A one-line text file with the coordinate reference system in WKT. The 1998 specification does not mention it, which is why so many old Shapefiles ship without one and why "my layer is in the ocean" is the most common support question in GIS.
• .cpg — optional. A one-line text file naming the .dbf encoding, for example UTF-8. Without it, readers guess.
• .sbn and .sbx — optional. ESRI's spatial index; ArcGIS writes them, GDAL-based tools read them but never write them, so they go stale after the first edit elsewhere.
• .qix — optional. The open spatial index written by GDAL, QGIS and MapServer. We created one with ogrinfo src.shp -sql "CREATE SPATIAL INDEX ON src" and a src.qix appeared next to the .shp.
• .shp.xml — optional. ArcGIS metadata (title, abstract, lineage) in XML. ArcGIS also stores field aliases there, and GDAL 3.13 and later reads .shp.xml to restore field names longer than 10 characters and their aliases; a GDAL-written Shapefile has no such file (none of our exports produced one).
• .ain and .aih — optional. Old ArcView attribute-index files. You can delete them.

Zip them together and you have a portable Shapefile; GDAL and our viewer both read the zip directly. We ran ogrinfo -so /vsizip/src.zip on a zip holding the five files above and it listed 1: src (Point) exactly as it does for the loose files.

If the .shx is missing

GDAL refuses to open the layer: ERROR 4: Unable to open src.shx or src.SHX. Set SHAPE_RESTORE_SHX config option to YES to restore or create it. The .shx can be rebuilt from the .shp, so the fix is what the message says: ogrinfo -so src.shp --config SHAPE_RESTORE_SHX YES rebuilt the index, and afterwards a new src.shx was sitting in the folder. Any GDAL-based tool, QGIS included, accepts the same option.

For the other six ways a missing file breaks a Shapefile, measured in the viewer and in GDAL, read Missing .shx or .dbf: why the Shapefile won't open.

If the .dbf is missing

The layer still opens, and that is the trap. We deleted the .dbf and ogrinfo -al -so src.shp reported Geometry: Point, Feature Count: 2 and the full CRS, with zero fields. Shapes on the map, no attributes, no warning. If "the attributes are gone", check for the .dbf first.

If the .prj is missing

The geometry opens, the attributes open, and the coordinate system is unknown. GDAL prints Layer SRS WKT: followed by (unknown). Desktop GIS will either ask you for a CRS, assume one, or load the layer with an unknown CRS and a question mark next to it — QGIS does whichever of the three its settings say — and if the file is in UTM metres, a layer treated as degrees lands nowhere near the map. The .prj section below is about this case.

For the step-by-step version — what GDAL, QGIS and our viewer each show for a .prj-less file, how to tell which CRS the numbers are actually in, and the assign-versus-reproject fix — read Shapefile in the wrong place: the missing .prj.

If the .cpg is missing

The file opens and the text may be wrong. The .dbf header has one "language driver" byte at offset 29; GDAL's default is 87, which it treats as Latin-1 (its debug log says Treating as encoding 'ISO-8859-1'). If the data was actually UTF-8, or the reader ignores the byte, accented characters come out as mojibake. The .dbf section below shows the bytes.

One geometry type per file

The .shp header carries one shape type for the whole file, and every record must match it. The 1998 specification defines fourteen shape-type codes: 0 for Null; 1, 3, 5 and 8 for Point, PolyLine, Polygon and MultiPoint; the same four with Z (11, 13, 15, 18) and with M (21, 23, 25, 28); and 31 for MultiPatch, an ESRI 3D surface type almost no open tool writes. In practice you meet four kinds of file — points, lines, polygons, multipoints — plus their 3D variants.

A GeoJSON or GeoPackage layer can mix points and lines. A Shapefile cannot. We converted a GeoJSON holding one Point and one LineString with ogr2ogr -f "ESRI Shapefile" out mixed.geojson. GDAL created a point Shapefile from the first feature and then stopped, printing ERROR 1: Attempt to write non-point (LINESTRING) geometry to point shapefile., ERROR 1: Unable to write feature 1 from layer mixed. and Terminating translation prematurely after failed translation of layer mixed (use -skipfailures to skip errors). The exit code was 1 and the output held one feature. If you need both, you need two Shapefiles; if you only need it to finish, -skipfailures still prints the same ERROR 1 for every mismatched feature but drops it and exits 0, so read the log before trusting the count.

Two subtleties that do not look like the rule but are:

• A polygon file holds single and multi-part polygons side by side. The format has no separate MultiPolygon type; a Polygon record simply has more than one ring. GDAL reads the two cases back as POLYGON and MULTIPOLYGON in the same layer, and that is what PostGIS and QGIS complain about as "mixed geometry types" on import. The fix is ogr2ogr -f GPKG out.gpkg in.shp -nlt PROMOTE_TO_MULTI; we ran it and the GeoPackage layer came out as Multi Polygon throughout.
• Null shapes are legal in any file. A record with shape type 0 means "attributes, no geometry". We exported a feature whose geometry was null into a point Shapefile and read the raw .shp: record 1 had shape type 1, record 2 had shape type 0, and ogrinfo listed both, the second with attributes and no POINT. Some viewers drop those rows; count your features after import.

Z and M variants store an elevation and a "measure" per vertex. GDAL will write them when asked: ogr2ogr -f "ESRI Shapefile" out in.geojson -nlt POINTZ produced a file ogrinfo reports as src (3D Point). Most web tools flatten the Z on read.

The .prj and the layer in the ocean

The .prj is a single line of WKT in ESRI's dialect of the 1.0 format. For WGS 84, GDAL writes GEOGCS["GCS_WGS_1984",DATUM["D_WGS_1984",SPHEROID["WGS_1984",6378137.0,298.257223563]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]] — note the GCS_ and D_ prefixes and the missing AUTHORITY clause. An ESRI .prj does not carry the EPSG code; readers match the parameters against a database to recover it. Usually that works; when the parameters are slightly off you get a "custom CRS" with the right shape and a wrong name.

The symptom everyone knows: the layer loads without error and appears thousands of kilometres away, often at latitude 0, longitude 0 off West Africa — "in the middle of the ocean". Nearly always the coordinates are projected metres with seven-digit northings, and the reader is treating them as degrees because the .prj was missing or wrong.

There are two different fixes and they are not interchangeable:

• Assign a CRS when the coordinates are correct and only the label is missing. This rewrites the .prj and touches no coordinates. ogr2ogr -f "ESRI Shapefile" fixed in.shp -a_srs EPSG:31982 — we ran it on a file with no .prj and the point stayed at POINT (-48.5 -27.6) while the new .prj declared SIRGAS_2000_UTM_Zone_22S. (Which, for a coordinate in degrees, is now a lie. Assigning the wrong CRS is the second most common way to put a layer in the ocean.)
• Reproject when the coordinates are correct in one CRS and you need them in another. This transforms every vertex. ogr2ogr -f "ESRI Shapefile" out in.shp -s_srs EPSG:4326 -t_srs EPSG:31982 — the same point became POINT (746752.990849492 6944611.29529316), in metres.

In QGIS the same two operations are "Set CRS" on the layer (assign) and "Export → Save Features As" with a different CRS (reproject), and choosing the wrong one produces the same disaster from the desktop. If you are unsure what a file is in, paste one of its coordinate pairs into our coordinate converter and try candidate systems until the point lands somewhere you recognise.

Regional datums you will meet in .prj files

The names below are what gdalsrsinfo reports for each code on our machine; the .prj will show the ESRI spelling, with underscores.

• EPSG:4326 — WGS 84, geographic. What GPS receivers, GeoJSON and web maps expect. A .prj that says GCS_WGS_1984 is this.
• EPSG:3857 — WGS 84 / Pseudo-Mercator, the projection of web map tiles. Nobody surveys in it; a Shapefile in 3857 came out of a web tool.
• EPSG:4269 — NAD83, geographic. The default of United States public data; a metre or two from WGS 84, fine for maps, wrong for survey work.
• EPSG:32622 — WGS 84 / UTM zone 22N, and EPSG:32722 for zone 22S. The 326xx and 327xx series are the northern and southern UTM zones on WGS 84; the last two digits are the zone.
• EPSG:4674 — SIRGAS 2000, geographic. The official datum of Brazil and most of South America; for practical purposes it coincides with WGS 84.
• EPSG:31982 — SIRGAS 2000 / UTM zone 22S, and EPSG:31983 for zone 23S. Between them these two cover most of São Paulo, Paraná, Santa Catarina and Rio de Janeiro; the 3197x/3198x series continues through Brazil's other zones.
• EPSG:4618 — SAD69, geographic. The Brazilian datum SIRGAS replaced; older municipal and utility Shapefiles are still in it, with UTM zones EPSG:29192 (22S) and EPSG:29193 (23S). SAD69 and SIRGAS 2000 differ by tens of metres, so "close enough" is not.
• EPSG:4225 — Córrego Alegre 1970-72, geographic. The datum before SAD69; you meet it in old cadastral maps and Shapefiles digitised from them.
• EPSG:4686 — MAGNA-SIRGAS, geographic. Colombia's national datum.
• EPSG:9377 — MAGNA-SIRGAS 2018 / Origen-Nacional. Colombia's single national projection, replacing the older regional origins.
• EPSG:5340 — POSGAR 2007, geographic. Argentina's national datum; the projected zones are EPSG:5343 through EPSG:5349 (Argentina 1 to 7, Gauss-Krüger).
• EPSG:5360 — SIRGAS-Chile 2002, geographic. Chile re-realises its frame every few years, so later files may say SIRGAS-Chile 2010, 2013, 2016 or 2021.
• EPSG:6365 — Mexico ITRF2008, geographic. The current Mexican national frame.

If a .prj names one of these and the layer still lands in the ocean, the wrong one was probably assigned at export; try the neighbouring candidates before you touch the data.

The .dbf will hurt you

The geometry side of a Shapefile is merely old. The attribute side is where your data gets damaged, silently, on the way out. We pushed one small dataset — a field named observation_notes, a UTF-8 value of São João, a NULL, an empty string, a 300-character note and an ISO timestamp — through ogr2ogr and read back what survived.

Field names are cut at 10 characters

The dBase header stores each field name in 11 bytes, one of which is a terminator. GDAL warns and then renames: Warning 6: Normalized/laundered field name: 'observation_notes' to 'observatio'. When two names collide it invents a suffix — observation_notes_final became observat_1. An earlier version of this guide said Populacao_2026 becomes Populaca_26; we tested that, and it is wrong. GDAL keeps the first ten characters, so it becomes Populacao_. Whatever your tool does, the year is gone.

This is permanent. Converting the Shapefile back to GeoPackage gave us fields still named observatio and observat_1. The names are not hidden anywhere; they were never written.

For the collision rule measured on a second dataset, and what a complete .shp.xml sidecar can and cannot restore, read Column name cut to 10 characters.

Latin-1 by default, and the .cpg sidecar

With a plain ogr2ogr -f "ESRI Shapefile" out in.geojson, GDAL did not write a .cpg file at all, set the language-driver byte at offset 29 to 87, and stored São João as the Latin-1 bytes Jo\xe3o — the UTF-8 sequence is nowhere in the file. GDAL reads its own output correctly because it honours that byte (the driver's ENCODING option defaults to LDID/87). A reader that assumes UTF-8 — most web code, most scripts that open the .dbf directly — shows Jo�o; a tool that re-encodes the Latin-1 text as UTF-8 and displays it as Latin-1 shows João, the é-style damage in every Latin American attribute table.

The fix on the writing side is one option: ogr2ogr -f "ESRI Shapefile" out in.geojson -lco ENCODING=UTF-8. The output then includes a src.cpg whose entire content is UTF-8, the header byte is 0, and the stored bytes are Jo\xc3\xa3o, genuine UTF-8. On the reading side, when someone hands you a Latin-1 file whose header byte says nothing (0) and that has no .cpg, tell GDAL: ogr2ogr -f GPKG out.gpkg in.shp --config SHAPE_ENCODING ISO-8859-1. We zeroed the language-driver byte of our own file to reproduce that case: without the option GDAL read S�o Jo�o, with it São João came back. (On the file as GDAL wrote it, header byte 87, the option changes nothing — GDAL already reads that as Latin-1.)

For the two directions of mojibake reproduced in the browser viewer, plus the one-line .cpg fix, read Wrong accents in a Shapefile: .cpg, Latin-1 and UTF-8.

NULL and empty string are the same thing

The .dbf has no NULL marker. An unset text field is padded with spaces, and so is an empty string. We wrote two features, one with nota set to null and one with nota set to ""; in the .dbf both records held eighty spaces, byte for byte identical, and ogrinfo read both back as (null). After a round trip into GeoPackage, SQLite reported typeof(nota) as null for both. "Not measured" and "measured, empty" have become one value, and the difference cannot be recovered. Numeric fields have the same problem in another form: some writers store an unset number as blanks, others as 0, and a reader cannot tell the second from a real zero.

254 characters of text, dates without time, and numbers as text

A character field has a one-byte width, so the ceiling is 254 characters. Our 300-character note produced Warning 1: Value '…' of field long_text has been truncated to 254 characters. This warning will not be emitted any more for that layer. — read the last sentence: the first truncation is announced, every later one is silent. The field came back as String (254.0) holding exactly 254 characters.

There is a date type, D, and it holds a calendar date and nothing else. A 2026-09-10 value became d: Date and survived. A timestamp did not: Warning 6: Field dt created as String field, though DateTime requested., and the field became String (29.0) — text that every downstream tool must parse and hope. There is no time zone and no time. There is a boolean, whatever you have read: the logical L type exists, and a true/false field we exported came back as Integer(Boolean) with the values 1 and 0. That particular complaint is a myth.

Numbers are stored as ASCII text with a fixed width and precision. A floating-point field came back as Real (24.15) — 24 characters, 15 decimals — and the value we wrote, 0.1234567890123456789, read back as 0.123456789012346. Integers become Integer (9.0) or Integer64 (18.0) depending on size. That is fine for measurements and wrong for identifiers that must match exactly.

2 GB, and GDAL will not stop you

The .shp stores offsets as 32-bit counts of 16-bit words and the .dbf has no offsets at all, so the spec itself does not stop at 2 GB — that ceiling is what ESRI software and most readers enforce, and it is the number everyone designs to. What we checked is GDAL's attitude: the 2GB_LIMIT creation option defaults to NO, so GDAL writes past it (with one warning as it crosses) and the next program fails — ArcGIS, an old MapServer, an upload form with a size cap. Data anywhere near that size should not be a Shapefile. Our GeoPackage guide covers the format that fixes every problem in this section, with the same experiments from the other side.

Open a Shapefile without QGIS

You do not need a desktop GIS to look at a Shapefile, read its attributes or find out what CRS it is in.

• Zip the sidecars together. Select the .shp, .shx, .dbf and .prj (and the .cpg if there is one), and compress them into one .zip. Do not zip the folder that contains them; zip the files. A lone .shp shows shapes without attributes.
• Drag the zip into the viewer. Drop it on our free Shapefile viewer: it accepts a .zip, a lone .shp, or the .shp plus .dbf plus .prj dropped together, and draws the features on a map. Click a feature to read its attributes, area or length and copy its WKT; open the attribute table to search and sort the whole file; pick a column as the map label. Up to ten files load side by side, which is the quickest way to see whether two layers actually overlap.
• Export from the browser. The viewer writes GeoJSON, KML and CSV, so "convert this Shapefile to GeoJSON" is a drag and a click with nothing installed.
• Privacy. All the parsing happens in your browser. No file is sent to any server; your files never leave your device. That is what makes it usable on data you are not allowed to send anywhere.

From the terminal, ogrinfo -so in.shp lists the layer and its geometry type, and ogrinfo -al -so in.shp adds the fields, the extent and the CRS without printing any features. Both come with GDAL, a single package install on Linux, macOS and Windows.

Converting out of Shapefile

Every command in this section was executed against real files before publication, with GDAL 3.13.3.

• Shapefile to GeoPackage: ogr2ogr -f GPKG out.gpkg in.shp. Field names stay as the .dbf has them (already truncated), text becomes real UTF-8, and NULLs are whatever the Shapefile could express, which is not much. The GeoPackage guide covers what to do next.
• Shapefile to GeoPackage when the source is Latin-1 (assume it is, unless there is a .cpg saying otherwise): ogr2ogr -f GPKG out.gpkg in.shp --config SHAPE_ENCODING ISO-8859-1.
• Shapefile to GeoJSON for the web — always reproject, the GeoJSON specification requires WGS 84: ogr2ogr -f GeoJSON -t_srs EPSG:4326 out.geojson in.shp. The output declares urn:ogc:def:crs:OGC:1.3:CRS84. If the input has no .prj the command fails with ERROR 1: Can't transform coordinates, source layer has no coordinate system. Use -s_srs to set one. — add -s_srs with the CRS you have established.
• Fix mixed single and multi-part polygons on the way: ogr2ogr -f GPKG out.gpkg in.shp -nlt PROMOTE_TO_MULTI.
• Shapefile to KML for Google Earth: ogr2ogr -f KML out.kml in.shp. The KML driver reprojects to WGS 84 on its own — our UTM file came out with <coordinates>-48.5,-27.6 — and writes the attributes into each placemark. A KMZ is the same KML inside a zip; building and opening one is covered in our guide on how to view KMZ files online.
• Writing a Shapefile without breaking accents: ogr2ogr -f "ESRI Shapefile" out_dir in.gpkg -lco ENCODING=UTF-8. You will still lose the field names past ten characters and every timestamp; the option only fixes the encoding.
• Only some features: ogr2ogr -f GPKG out.gpkg in.shp -where "status = 1" filters on attributes, and -clipsrc xmin ymin xmax ymax clips to a box.
• Rebuild a lost index file: ogr2ogr -f "ESRI Shapefile" fixed in.shp --config SHAPE_RESTORE_SHX YES. We ran it on a folder with no .shx; the copy in fixed had one, and so did the source folder afterwards — the option restores the index in place.

The -nln flag names the output layer in formats that have layer names; skip it and you inherit the Shapefile's base name, which is fine until that name is export (2) final.

Errors, decoded

Each entry is symptom, cause, fix. The messages are quoted from GDAL 3.13.3; QGIS surfaces the same text in its log panel.

"Unable to open .shx"

Symptom: ERROR 4: Unable to open in.shx or in.SHX. Set SHAPE_RESTORE_SHX config option to YES to restore or create it. and the layer does not load. Cause: the index sidecar was not copied with the .shp. Fix: ogrinfo -so in.shp --config SHAPE_RESTORE_SHX YES rebuilds it in place; then copy the whole set next time.

"Layer has no CRS" or (unknown)

Symptom: ogrinfo prints Layer SRS WKT: and then (unknown); QGIS shows a question mark next to the layer or asks for a CRS. Cause: no .prj. Fix: work out what the coordinates are (two digits before the point are degrees, EPSG:4326; six-digit eastings with seven-digit northings in Brazil are a 3198x zone), then assign, not reproject: ogr2ogr -f "ESRI Shapefile" fixed in.shp -a_srs EPSG:31982.

"Normalized/laundered field name"

Symptom: Warning 6: Normalized/laundered field name: 'observation_notes' to 'observatio' at export, and a colleague later asks what observat_1 means. Cause: the 10-character limit. Fix: none inside the .dbf; ArcGIS keeps the long name as an alias in .shp.xml, and GDAL 3.13+ reads it back — a GDAL-written Shapefile has no such file. Rename fields to ten characters or fewer before exporting so you choose the abbreviations, or keep a GeoPackage and treat the Shapefile as a lossy copy.

Accents show as é or �

Symptom: São João renders as São João or S�o Jo�o. Cause: a Latin-1 .dbf read as UTF-8, or the reverse; there is no .cpg to settle it. Fix: on read, --config SHAPE_ENCODING ISO-8859-1 (or UTF-8, whichever the file actually is); on write, -lco ENCODING=UTF-8 so a .cpg gets written and the next reader does not have to guess.

"File too large" or a .dbf that other software rejects

Symptom: GDAL wrote the file, printing one warning as it crossed 2 GB; ArcGIS, an upload form or an older library refuses it, or reads garbage past some feature. Cause: a .shp or .dbf past 2 GB, which GDAL allows by default (2GB_LIMIT=NO). Fix: split the data, or stop using Shapefile for it — ogr2ogr -f GPKG out.gpkg in.shp has no such ceiling.

"Attempt to write non-point geometry to point shapefile"

Symptom: ERROR 1: Attempt to write non-point (LINESTRING) geometry to point shapefile. followed by Terminating translation prematurely, and an output with fewer features than the input. Cause: the source mixes geometry types and a Shapefile holds one. Fix: export one Shapefile per type with the geometry filter — ogr2ogr -f "ESRI Shapefile" points in.geojson -where "OGR_GEOMETRY='POINT'" and again with 'LINESTRING'; we ran both and got a Point layer and a Line String layer with no errors. Or keep the data in a format that allows mixing.

Features do not draw, or draw in the ocean

Symptom: the layer loads with no error and is invisible, or sits at latitude 0, longitude 0. Cause: a missing or wrong .prj, so projected metres are read as degrees or the reverse. Fix: check ogrinfo -al -so in.shp for Layer SRS WKT; compare the Extent line with what the numbers should look like in the CRS you expect; assign the right CRS. If the extent is right and the layer is still invisible, check the Feature Count — a file of Null shapes has nothing to draw.

Shapefile vs GeoPackage vs GeoJSON

No table — just pick the sentence that matches your situation.

Shapefile is still the right answer when the other side accepts nothing else. That is real and common: government geoportals, old municipal systems, utility asset software, surveying packages and a good number of ArcGIS installs import a Shapefile and nothing else, and it is the format most likely to open in a tool you have never heard of. When that is the constraint, export with -lco ENCODING=UTF-8, choose your ten-character field names on purpose, ship the .prj, and keep the original in a format that lost nothing.

GeoPackage is the right answer when the data is yours to keep: many layers, mixed geometry types, real field names, real NULLs, real timestamps, one file with the CRS inside it. It is the correct default for desktop GIS and field work, and what a Shapefile should become on arrival.

GeoJSON is the right answer when a browser or an API will read it, or a human needs to open it in a text editor. It is bound to WGS 84 by specification, has no index and gets heavy past a few megabytes, none of which matters for the "send these forty points to the frontend" case it exists for.

And none of them are right when several people need to write at the same time. That is a database, not a file.

For the measured version of this comparison — sizes, field-name limits, encoding, CRS and load time on one real dataset — read Shapefile vs GeoPackage vs GeoJSON: which to use.

Where Geodocs fits

We build Geodocs, a platform for field data and GIS teams, and we wrote this guide because a large share of what our users upload is a Shapefile, and a large share of the support conversations that follow are one of the seven errors above. So the platform handles them: it takes a zipped Shapefile as one upload, detects the .dbf encoding instead of assuming it, reads the .prj and reprojects to the map, and keeps the data where a field name can be longer than ten characters and a NULL stays a NULL. If your team is still emailing five-file folders and hoping the .prj made it, that is the problem we exist to remove.

Spotted an error, or a gotcha we missed? Tell us. We re-run this page rather than copy-pasting it.

Last verified: 10 September 2026, GDAL 3.13.3.