Passage Data

Check a file →

Why your shapefile column names are cut to 10 characters

Shapefile · dBASE III/IV

What you are seeing — your columns came back as beschermin, sitecode_v and individual, and the names you actually gave them are gone.

The short answer

The cap is real and it is not in the shapefile specification. The spec delegates the attribute table wholesale to dBASE. Two other facts produce the 10: the dBASE III/IV field descriptor allots 11 bytes for a name, and ESRI's own software caps it at 10 (ArcGIS error 000142).

That distinction matters if you are writing a reader — believing the cap is 10 in the format truncates a legal 11-byte name by one character on every file not written by ArcGIS, silently. We read 11 bytes and stop at the first NUL.

For everyone else the consequence is simpler and worse: the original spelling is not recoverable from the file. The export destroyed it before you ever saw it. Nothing can undo that — not us, not a GIS, not the person who sent it, unless they still have what they exported from.

It is also why a column should be confirmed from its values rather than its header. scientific could be a scientific name or a scientific method; the values settle it and the header cannot.

If you are choosing a format now, this is the strongest single argument for GeoPackage: it has no cap at all.

What you can still do

  1. Ask whoever exported it for the source layer, if it still exists. That is the only place the full names survive.
  2. Drop the file here and read the truncated list — we name every column sitting at the cap, and every pair that would have collided if two names started the same way.
  3. Where two names collided, the export usually renamed one — so a column may not hold what its stub suggests. Check the values before trusting the header.
  4. Re-export as GeoPackage if you control the source, and the problem does not recur.
See which names were cut

Drop the zipped bundle or the bare .dbf and we will name every column that hit the cap. Free until 1 September 2026, 00:00 UTC · no account · your rows are discarded after the check.

Check the file you have →

Why we can say that

5,064records already published to GBIF
0findings in GBIF's vocabulary
4,268findings from ours
31.7%came back clean

Measured on a file GBIF had already accepted and served — their validator asks will this load, and it had. Every figure is read from ops/data.json, never typed here. We issue no rating and no seal — each finding names the rule it applied.

Related