Build a Darwin Core archive from a species file or a list of names
A file this tool reads, sent or fetched from the address given, is read as one dropped on our website: what the read finds (column headings, the shape of its rows, the terms they became, refusal codes) is kept so the reader learns, never the file or its values. Names and contacts are dropped or replaced by a code, and protected species' locations are made coarser. A species occurrence or checklist file (CSV, TSV, Excel, a zipped shapefile, ...) given as file_url (a public https address the door fetches) or content_base64, or a list of scientific names (species, a checklist), becomes a Darwin Core archive for GBIF: occurrence.txt or taxon.txt, meta.xml and eml.xml, built by the converter behind map_to_darwin_core, which maps every column and checks every value. The zip comes back whole in archive.base64, with each thing the converter would not guess coded in could_not_read (the same lines ship inside the archive as passage-data-exceptions.csv and .json). GBIF indexes an archive only with a title, an abstract, a licence and a creator and a contact (given name, surname, organisation, email): give them in metadata; nothing is filled in. chapman_category (1-4, the data holder's own Chapman 2020 category) coarsens the coordinates of species a conservation register lists. columns names the column for a term where your user decided; the values are still checked. With columns_confirmed_by_user: true (your user confirmed every entry) each confirmed column's words and term, never a value, are also read as a label to teach the converter, said in learned. A large file takes up to a minute.
Request
- Base URL: https://passage-data.com/api/v1
- URL: https://passage-data.com/api/v1/dwc/archive
- Auth: one of:
- none
- HTTP bearer
- API key in header x-api-key
Request body
Response
The archive (base64) and its receipt, what could not be read, notices
Changes
No recorded changes to this operation across all 1 revision of this API.