I have opened enough old folders to know the feeling. Hundreds of images, a CSV with columns called “val1” and “val2”, and a filename that once meant something to someone. The data are all there. But it is often enough a big puzzle and the meaning has gone.
That is what metadata are for. They are the context that turns a number, an image or a spectrum into an observation that someone else can trust. And the good news is that you do not have to invent this context from scratch. Several communities have already thought hard about it, and borrowing their frameworks is one of the easiest wins in proximal sensing.
What metadata actually need to answer
Before standards, the questions. Who collected this? Where, exactly, and when? What was the sensor looking at? Which instrument, mounted how, with which settings? And what do the stored values mean: raw counts, reflectance, an index, a calibrated estimate?
Is the timestamp UTC or local time? Was the camera moved after that storm in March? If your records cannot answer these, a future user (quite possibly you, three years from now) will be guessing.
Start with the FAIR principles
The FAIR principles, published by Wilkinson and colleagues in 2016, ask that data be Findable, Accessible, Interoperable and Reusable. They are not a file format or a template. They are a checklist of intentions.
For a field sensor this translates into fairly concrete habits: give sites, deployments and instruments persistent identifiers; store data in open formats; use shared vocabularies (ontologies) where they exist; and attach a clear licence. Reusable is the hard one. Reuse depends almost entirely on whether the context was written down.
PhenoCam: a working example of good practice
Let’s start with the obvious framework for proximal sensing or at least camera data. If you want to see what metadata discipline looks like in a real proximal sensing network, look at PhenoCam. Every camera site in the network carries a structured record: location, elevation, vegetation type, camera model, mounting height and view direction, and a description of the scene. Regions of interest (ROIs) are defined as masks, versioned, and tied to a specific date range. When a camera is moved or replaced, a new ROI is created rather than silently reusing the old one.
The released datasets, such as PhenoCam Dataset v2.0, go further. Time series of green chromatic coordinate (GCC) are published together with the processing version, the ROI identifier and quality flags. That combination is why images from very different sites and cameras can be compared at all.
I find PhenoCam’s approach useful even for a single camera in a single field. You do not need to join the network to adopt its logic: one site record, versioned ROIs, a log of camera changes, and the processing version stored next to the output.
The European counterparts are worth knowing too. ICOS ecosystem stations follow published instructions for phenocam set-up and ancillary measurements, and the European Phenology Camera Network (EUROPhen) has worked on harmonising practice across sites.
ISO 19115 and ISO 19156: the formal backbone
For geographic data, ISO 19115-1 (and the later versions) is the international metadata standard. It defines how to describe a dataset: identification, extent in space and time, lineage, quality, contacts, constraints and distribution. Many national and European catalogues, including those built for INSPIRE, are based on it.
ISO 19156, Observations, measurements and samples (developed jointly with OGC), is arguably even closer to the heart of proximal sensing. It models an observation as an event: a procedure (your sensor and method) produces a result about a property (canopy greenness, soil moisture) of a feature of interest (a maize plot), at a given time. That vocabulary is surprisingly helpful when you design your own templates. If your metadata can fill in each of those slots, you are in good shape.
You do not have to write ISO-compliant XML by hand. But mapping your spreadsheet columns to these concepts makes later conversion straightforward.
OGC SensorThings and the SOSA/SSN ontology
For live sensor systems, the OGC SensorThings API offers a practical data model: Things, Locations, Datastreams, Sensors, ObservedProperties and Observations. It is built on the same observation concepts as ISO 19156, and there are open-source servers that implement it. If you run LoRaWAN or ESP32 nodes, it is a sensible target structure even if you start with something simpler.
The W3C and OGC SOSA/SSN ontology does the same job for linked data. It is the route to take if you want your sensors and observations described in a machine-readable way on the web.
Instruments and calibration have standards too
Metadata about the measurement itself are often where the gaps are. Here, too, existing frameworks help. The WMO Guide to Instruments and Methods of Observation sets out siting, exposure and maintenance expectations for meteorological sensors. Radiation sensors are classified under ISO 9060, and calibration laboratories work to ISO/IEC 17025. Referring to these in your metadata (“pyranometer, ISO 9060 class B, calibrated 2025 against a reference traceable to the WRR”) says far more than “light sensor”.
For spectral measurements, the reflectance terminology described by Schaepman-Strub and colleagues is worth adopting. Writing “hemispherical-conical reflectance factor” instead of just “reflectance” removes a lot of ambiguity.
Describe the target, not only the sensor
Hardware is usually documented reasonably well. The target is not. “Vegetation camera” says very little. Is it a maize canopy, a grassland treatment plot, a mixed forest edge? Did the crop grow into the field of view, was the plot mown, did snow cover the scene?
Record species or crop, management, plot boundaries, intended footprint and known heterogeneity. A few site photographs and a simple map are often worth more than a page of prose.
Geometry, time and change history
Record location, height, orientation, viewing angle, field of view and footprint, and keep a reference image with landmarks. Store timestamps in UTC in the primary record and document local time conventions separately.
Then log every change: a new lens, a moved mast, a replaced probe, a revised ROI, a firmware update, a cleaning event. Each of these can break comparability. They belong in the metadata, not in an email thread.
A practical starting point (a small beginning is better than nothing!)
You do not need a full infrastructure on day one. A deployment form, a readme, a site map, a maintenance log and a version-controlled processing repository already cover most of what the standards ask for. Structure those using the PhenoCam site record as a model and the ISO 19156 observation concepts as a checklist, and you can map them to ISO 19115 or SensorThings later without starting again.
Leave a useful trace
The test is simple. Could a capable researcher (or even a student in this field) who was never involved in your project understand and responsibly reuse your data? If not, what is missing is probably metadata. And in most cases, someone has already written a standard that tells you what to add.
Further reading
Wilkinson, M. D., Dumontier, M., Aalbersberg, I. J., Appleton, G., Axton, M., Baak, A., Blomberg, N., Boiten, J.-W., da Silva Santos, L. B., Bourne, P. E., Bouwman, J., Brookes, A. J., Clark, T., Crosas, M., Dillo, I., Dumon, O., Edmunds, S., Evelo, C. T., Finkers, R., Gonzalez-Beltran, A., Gray, A. J. G., Groth, P., Goble, C., Grethe, J. S., Heringa, J., ‘t Hoen, P. A. C., Hooft, R., Kuhn, T., Kok, R., Kok, J., Lusher, S. J., Martone, M. E., Mons, A., Packer, A. L., Persson, B., Rocca-Serra, P., Roos, M., van Schaik, R., Sansone, S.-A., Schultes, E., Sengstag, T., Slater, T., Strawn, G., Swertz, M. A., Thompson, M., van der Lei, J., van Mulligen, E., Velterop, J., Waagmeester, A., Wittenburg, P., Wolstencroft, K., and Zhao, J., Mons, B. (2016). The FAIR Guiding Principles for scientific data management and stewardship. Scientific Data, 3, 160018. https://doi.org/10.1038/sdata.2016.18
Seyednasrollah, B., Young, A. M., Hufkens, K., Milliman, T., Friedl, M. A., Frolking, S., & Richardson, A. D. (2019). Tracking vegetation phenology across diverse biomes using Version 2.0 of the PhenoCam Dataset. Scientific Data, 6, 222. https://doi.org/10.1038/s41597-019-0229-9
Richardson, A. D., Hufkens, K., Milliman, T., Aubrecht, D. M., Chen, M., Gray, J. M., Johnston, M. R., Keenan, T. F., Klosterman, S. T., Kosmala, M., Melaas, E. K., Friedl, M. A., & Frolking, S. (2018). Tracking vegetation phenology across diverse North American biomes using PhenoCam imagery. Scientific Data, 5, 180028. https://doi.org/10.1038/sdata.2018.28
Haller, A., Janowicz, K., Cox, S. J. D., Lefrançois, M., Taylor, K., Le Phuoc, D., Lieberman, J., García-Castro, R., Atkinson, R., & Stadler, C. (2019). The modular SSN ontology: A joint W3C and OGC standard specifying the semantics of sensors, observations, sampling, and actuation. Semantic Web, 10(1), 9–32. https://doi.org/10.3233/SW-180320
Leave a Reply