Occurrence and collection mode

​NaturaList supports a collection mode in which individual occurrence records are attached to taxa in the taxonomic tree. This transforms the app from a simple species database into a collection management or annotated occurrence tool - for example, a type occurrence index, a herbarium collection, a locality-based survey database, or an annotated inventory where each species entry is backed by individual occurrence records.

The two levels - taxon rows and occurrence rows - coexist in the same spreadsheet and can be explored independently. The feature is entirely optional: you can mix taxa with and without occurrences freely.

How the app detects occurrences

Detection is convention-based and requires no special configuration switch. The app scans the Taxa definition table for a taxon level whose Taxon name is exactly Occurrence (case-insensitive). If found, every data row whose cell at that taxon column is non-empty is treated as a occurrence record.

Important distinction

Detection is based on the value in the Taxon name column (the human-readable label shown in the UI), not the Column name (the spreadsheet column header). You can name your spreadsheet column anything (e.g. specid, voucher, cat_no) - what matters is writing Occurrence as the Taxon name in the Taxa Definition table for that row.

The occurrence level must be the last row in the Taxa Definition table, appearing below all other taxon ranks.

Spreadsheet structure

Occurrence rows are ordinary rows in the data sheet, following the same structure as all other (Taxa) rows. An occurrence row:

• Has values in all parent taxon columns (the same taxon name they belong to - e.g. the species name in the Species column).
• Has a non-empty value in the occurrence column (e.g. a catalogue number, a field code, a voucher reference).
• May have any custom data columns referenced in Custom data definition table, filled in with occurrence-specific data (locality, collector, date, coordinates, institutional accession, etc.) and with Belongs to set to occurrence.

Example data sheet layout:

Family	Species	occurrenceID	Locality	CollectionDate	gps.lat	gps.long	redList	status
Ericaceae
Ericaceae		MNHN-P-000156	Barre des Écrins, France	1994-07-01	45.024	6.431
Ericaceae	Rhododendron ferrugineum						EN	native
Ericaceae	Rhododendron ferrugineum	MNHN-P-001234	Col du Lautaret, France	1978-06-14	45.034	6.401
Ericaceae	Rhododendron ferrugineum	W-0023567	Hohe Tauern, Austria	2003-08-02	47.118	12.731

The taxon rows (row 1 and 3) hold species/taxon-level data (range description, IUCN status, etc.) while each occurrence row (rows 2, 4, 5) holds occurrence-specific data.

A dataset can also contain occurrence rows without a corresponding taxon-only row above them, if you don't need specific taxon-level data included with that taxon - the app infers the parent taxon from the shared taxon column values. In the example above the first row (family) is in fact unnecessary from data standpoint, though completely harmless.

Taxa definition table for the above:

Column name	Taxon name	Order by	Parent taxon indication	Italicize
Family	Family	alphabet
Species	Species	alphabet	Family	yes
occurrenceID	occurrence

Data inheritance

For the Trait Matrix analysis tool, the app implements parent-data inheritance for occurrence rows: when displaying a occurrence record, the app merges the occurrence's own data with the data from its parent taxon row. Structural fields (plain text, arrays) give priority to occurrence data for scalar values and concatenate arrays; atomic fields (mapregions, months) preserve the parent value unless the occurrence overrides it.

This means you can store shared species-level data (habitat, Red List status, distribution map) on the taxon row and occurrence-specific data (locality, date, collector) on each occurrence row without repeating species data on every occurrence row.

UI behaviour in collection mode

When at least one occurrence record is present, the app activates a Data Scope toggle in the Configuration Dialog (top-right button). Users can switch between:

• Taxa scope - the standard view, showing only taxon-level rows.
• Occurrences scope - shows individual occurrence records nested under their parent taxa.

Recommended use cases

Scenario	Approach
Type occurrence index	Add an Occurrence taxon level with catalogue number, institution, and type status columns
Herbarium / museum collection	Most rows are occurrences; taxon rows provide aggregate species/taxon-level data
Survey data with locality records	Taxon rows summarise presence; occurrence rows are georeferenced occurrence records
Annotated inventory with vouchers	Mixed: some species have occurrences, others do not

Practical tips

• Use geopoint data type for locality coordinate columns to make each occurrence's location a clickable map link to external map services like Google Maps or OpenStreetMap.
• Use date data type for collection date columns so they render according to the project's date format setting and can be range-filtered.
• Database shortcodes are particularly useful in collection contexts: you can encode references to GBIF occurrence records, iNaturalist observations or your own online database or collection simply records using @engine:ID notation. These render as formatted hyperlinks automatically.
• mapregions data type with notes are especially useful in collection mode: each region entry can carry notes with locality data, dates, and collector names, rendered as superscript footnotes in the inline list.