395
• Processing information: Consider including information on software or programming language and version; provide well-documented code and information about data transformation.
• Quality checks: Ensure that data are delimited and lined up in proper columns;
check that there are no missing values (blank cells); scan for impossible and
anomalous values; perform and review statistical summaries; and map location data.
• Documentation: Document content of data set; reason for data collection; investigator; current contact person; time, location, and frequency of data collection;
spatial resolution of data; sampling design; measurement protocol and methods
used, including references; processing information; uncertainty, precision, accuracy, and known problems with the data set; processing information; assumptions regarding spatial and temporal representativeness; data use and distribution
policy; ancestors and offspring of data set (including references to
publications).
• Data protection: Create backup copies often and without user interference (automatically, continuously, incrementally); three copies (original, on-site external,
off-site) are ideal; test restoring information; and use checksums to ensure that
copies are identical.
• Data preservation: Preserve well-structured data files with variables, units, and
values defined; documentation and metadata records; materials from project
wiki/websites; files describing the project, protocols, and field sites (including
photos); and project proposal (at least parts) and publications in open-access
archives. Check platform standards for data archiving beforehand.
The best way to organize data depends on the project, size of the team, and
degree of interaction among team members, among other things. It is good practice
to think about ways to organize data early in the project-planning phase and to
include at least the core project team in these discussions. However, differences in
personal work styles can be a challenge for reaching agreements; the larger the
team, the more difficult this becomes. In such cases, top-down approaches to data
organization can be a good option, especially ones that have been tested before.
Laying out data organization schemes at an early project stage and inviting people’s
feedback at this stage is good practice. Clearly, there should be room for discussion
during later project stages as well (particularly when the existing organization
scheme is not working as expected), but generally adjustments become more complicated the longer projects are running. Data organization schemes are intended to
make daily workflows, data exchange, and data archiving easier; they should not
cause an extra workload. Research teams are much more likely to adapt a particular
organizing scheme when it is simple and intuitive, and everyone is much more likely
to stick to a system when its benefits are obvious. In the end, even the best organization structure fails when no one is following it.
15 Spectral Field Campaigns: Planning and Data Collection
• Processing information: Consider including information on software or programming language and version; provide well-documented code and information about data transformation.
• Quality checks: Ensure that data are delimited and lined up in proper columns;
check that there are no missing values (blank cells); scan for impossible and
anomalous values; perform and review statistical summaries; and map location data.
• Documentation: Document content of data set; reason for data collection; investigator; current contact person; time, location, and frequency of data collection;
spatial resolution of data; sampling design; measurement protocol and methods
used, including references; processing information; uncertainty, precision, accuracy, and known problems with the data set; processing information; assumptions regarding spatial and temporal representativeness; data use and distribution
policy; ancestors and offspring of data set (including references to
publications).
• Data protection: Create backup copies often and without user interference (automatically, continuously, incrementally); three copies (original, on-site external,
off-site) are ideal; test restoring information; and use checksums to ensure that
copies are identical.
• Data preservation: Preserve well-structured data files with variables, units, and
values defined; documentation and metadata records; materials from project
wiki/websites; files describing the project, protocols, and field sites (including
photos); and project proposal (at least parts) and publications in open-access
archives. Check platform standards for data archiving beforehand.
The best way to organize data depends on the project, size of the team, and
degree of interaction among team members, among other things. It is good practice
to think about ways to organize data early in the project-planning phase and to
include at least the core project team in these discussions. However, differences in
personal work styles can be a challenge for reaching agreements; the larger the
team, the more difficult this becomes. In such cases, top-down approaches to data
organization can be a good option, especially ones that have been tested before.
Laying out data organization schemes at an early project stage and inviting people’s
feedback at this stage is good practice. Clearly, there should be room for discussion
during later project stages as well (particularly when the existing organization
scheme is not working as expected), but generally adjustments become more complicated the longer projects are running. Data organization schemes are intended to
make daily workflows, data exchange, and data archiving easier; they should not
cause an extra workload. Research teams are much more likely to adapt a particular
organizing scheme when it is simple and intuitive, and everyone is much more likely
to stick to a system when its benefits are obvious. In the end, even the best organization structure fails when no one is following it.
15 Spectral Field Campaigns: Planning and Data Collection