Shapefile → Darwin Core Archive
What you are seeing — your survey lives in a shapefile, and every route into GBIF assumes you already have Darwin Core.
GBIF does not ingest shapefiles. It wants a Darwin Core Archive — a zip holding a delimited table, a meta.xml naming which column is which Darwin Core term, and an eml.xml describing the dataset. Most publishers never build that zip by hand: they put a flat table into an IPT (the Integrated Publishing Toolkit, usually one hosted by their national node), and the IPT assembles the archive.
Which means the hard part is not the publishing. It is the export. By the time your data reaches an IPT it is a table, and every decision that can silently corrupt it was made on the way out of the shapefile. The four below are the ones that actually go wrong, in the order they bite.
① The CRS, and this is the big one. A shapefile stores coordinates in whatever system its .prj declares, and exporting to CSV does not reproject them unless you ask. If the .prj names a UTM zone, a state plane, or a national grid, the numbers that land in your latitude column are metres — six or seven figures, obviously wrong, and at least they fail loudly. The dangerous case is the quiet one: a file already in degrees but on a different datum (NAD27, ED50, an old national datum) exports as perfectly plausible latitudes that are tens to hundreds of metres from the truth, and nothing downstream will query them.
And Darwin Core does not rescue you here, because it does not assume WGS 84. This is widely misunderstood, including by us until we checked the standard: decimalLatitude is defined as "a geographic latitude (in decimal degrees, using the spatial reference system given in dwc:geodeticDatum)". The datum is whatever you declare — not a default. So reproject to EPSG:4326 and populate geodeticDatum; TDWG's own recommendation is to give the EPSG code. A record with coordinates and no declared datum is asking every downstream user to guess, and they will guess WGS 84 whether or not that is what you meant.
② Points versus polygons — a decision no tool should make for you. A Darwin Core occurrence is a point observation. If your features are polygons or lines, reducing them to a centroid invents a coordinate nobody recorded, and for a crescent, a ring or a river reach the centroid is not even inside the feature. Darwin Core has the honest fields: footprintWKT for the geometry itself, and footprintSRS for its reference system — which is declared independently of the point coordinates, so a footprint in the survey's native projection and a point in WGS 84 can coexist without either being a lie. We refuse non-Point geometry by name rather than centroiding it, which is the same rule stated from our side.
③ Your column names were already destroyed. Field names in a shapefile are capped at 10 characters, so coordinateUncertaintyInMeters became coordinate the moment somebody saved the file, and the original spelling is not recoverable from it. The cap is worth stating precisely, because almost everyone attributes it to the wrong place: the shapefile specification itself says nothing about it and defers the attribute table to the dBASE format, whose field descriptor allots 11 bytes for a name. The 10 is ESRI's software — ArcGIS refuses a longer one outright. The practical effect is the same everywhere; only the provenance differs. Any tool that maps your columns by matching header names is working from a truncated, ambiguous string. This is exactly why we confirm a column from the values inside it instead: on 5,064 records that had already been published to GBIF and passed their pipeline, that method still surfaced 4,268 findings, 0 of which were in GBIF's own vocabulary.
④ Encoding, which bites last and hardest on names. A .dbf carries no reliable declaration of its own character set. If a .cpg file sits beside it, that names the encoding; if not, you are guessing, and the usual answer is a Windows single-byte code page. Get this wrong and accented locality names and non-English vernacular names arrive mangled — and a mangled species string is not a cosmetic problem, it is a name that will not match anything.
.shp in QGIS (free) and read the layer's CRS. Compare it against the .prj rather than assuming they agree — a missing or wrong .prj is common, and QGIS will happily show you a guess.footprintWKT with footprintSRS.geodeticDatum to EPSG:4326 in the exported table, as a real column. It is one value repeated on every row and it removes an ambiguity nobody downstream can resolve for you.coordinateUncertaintyInMeters. If the point is a polygon's centroid, the honest uncertainty is the radius of that polygon, not your GPS's accuracy.Upload the zipped bundle (.shp/.shx/.dbf/.prj together) and we open it without any of the export steps above: every attribute column, the CRS exactly as your .prj states it, the encoding — and, on the first sheet of what comes back, exactly what the shapefile format already did to your column names before you ever got here (the 10-character cut, any collisions, and which of those are unrecoverable without a second source). Free, permanently. It does not reproject your coordinates or decide points-versus-footprints for you — those stay yours, and the steps above are still how you get them right before you export. Free until 1 September, no account, and your records are discarded after the check —
we keep the column mapping, never the rows.
We audited a file GBIF had already accepted and served. Their validator answers will this load; these had loaded. Figures read from ops/data.json, not typed into this page. We do not issue a rating of any kind — every finding names the rule it applied and where that rule comes from.