A measurement is a chain of decisions
A proximal sensing project rarely fails because a researcher or student chose the wrong analysis or algorithm at the end. More often, the problems begin much earlier. The target was not clearly defined, the sensor was installed without a stable geometry, reference observations were collected too late, metadata were incomplete, or a field system was treated as if it could operate without maintenance.
A useful proximal sensing workflow makes these decisions visible. It connects the scientific or practical question with the target, sensor, acquisition design, quality control, processing, validation, interpretation, and eventual use of the result. The sequence is not always linear. Field work often involves iteration. It is usually better to start small, learn from the first deployment, and then scale up than to build a large system around assumptions that have never been tested.
Thinking through the full chain before deployment does not prevent every problem, but it makes the system more robust and the resulting data much easier to interpret.
Start with the question and target
The workflow begins with the research question, not the instrument. “Which sensor should we use?” is usually too early a question. A better starting point is the process we want to understand or the decision that requires evidence.
A crop researcher may want to identify uneven development. A hydrologist may need continuous observations of water level. A soil scientist may want to map field variability. An ecologist may be interested in the timing of canopy development.
The target then needs to be defined at an appropriate scale. A leaf is not a canopy. A canopy is not a field. A soil probe measures a limited volume around the sensor. It is a point measurement, not a measurement of an entire management zone. A camera ROI (region of interest) may represent one part of a scene from one particular angle, but it does not automatically represent everything around it.
This matters because the target definition determines the appropriate sensor footprint, spatial resolution, sampling frequency, and reference measurements.
Before choosing a sensor, it is worth being able to answer a simple question: What exactly do we want the measurement to represent?
Design the observation
Sensor selection follows from the target and the evidence we need. For example, imagine that the goal is to monitor crop development with a fixed camera. A camera with a high-resolution sensor might seem like the obvious choice. But resolution is only one consideration. If the camera cannot store enough images for the intended deployment, consumes too much power, changes its exposure between images, or cannot withstand the field conditions, its high resolution may not be particularly useful. That’s why a useful design considers spectral or physical sensitivity, precision, spatial footprint, temporal resolution, field durability, power demand, storage, communication, cost, calibration requirements, and practical access to the site.
Deployment design is equally important. Sensor-target distance, viewing angle, field of view, orientation, mounting height, sampling position, time of day, and expected environmental conditions all influence the signal. These choices should be recorded before the first measurement, ideally with photographs and a simple site sketch. Six months later, it can be surprisingly difficult to remember exactly how a sensor was positioned, even when the setup seemed obvious at the time.
Start small, scale up
A pilot deployment is often worth the effort. I made it a rule to test field setups in smaller pilots before starting any of my larger deployments. This helps avoid scaling small problems into large field campaigns. A pilot can reveal whether the target actually fills the intended camera frame, whether a sensor overheats, whether the solar panel is large enough, whether a wireless connection is reliable, whether a tower moves in strong wind, or whether vegetation will soon obstruct the field of view.
Here in the Netherlands, for example, insufficient solar power can become a surprisingly important problem during periods of cloudy weather or periods with very little sunshine like January. A system that works perfectly for several sunny weeks may behave very differently once winter arrives.
I also redesigned a camera cover once because spiders apparently loved the position of the camera and repeatedly built their webs directly in front of the lens. The problem was easy to solve once we knew about it. It would have been much less amusing to discover it after several months of automated data collection.
These are small examples, but they illustrate an important point. A pilot is not just a test of whether the sensor works. It is a test of whether the entire observation system works in the place and conditions where it will actually be used.
Small problems found early are much cheaper than lost seasons of data.
Acquire with context
Data acquisition is not just the automatic recording of values. It also includes the context that makes those values understandable. Field notes, meteorological data, photographs taken with a phone, maintenance actions, management events, camera changes, sensor replacements, and unusual conditions can all explain patterns that would otherwise look mysterious in the final dataset.
For long-running systems, it helps to establish a simple operational routine. This can be nothing more complicated than a checklist on your phone that you use whenever you visit the field.
Are data still arriving? Are the clocks still correct? Is there enough power? Is the lens clean? Is there a spider web in front of it? Is the sensor still in the correct position? Has anything changed around the site? Are the files backed up? These checks may seem so mundane, but they are part of the measurement process. A system can produce a continuous stream of data and still fail silently. A camera can keep taking pictures after it has been moved. A sensor can keep recording after its installation has changed. A time series can continue to look perfectly plausible while no longer representing the target we intended to observe.
Quality control before analysis
Quality control should begin immediately, not after the final field campaign.
Inspect the first observations. Plot the time series. Look at some of the actual images. Check for missing records, sudden jumps after maintenance, impossible values, repeated images, unexpected flat lines, or changes that correspond to shadows, rain, sensor drift, or communication problems. The appropriate checks depend on the sensor. For cameras, check lens obstruction, scene movement, exposure changes, and ROI stability. For soil probes, consider installation quality, sensor contact, depth, and drift. For thermal or multispectral systems, inspect reference targets, calibration behaviour, and environmental influences.
Good quality control is not simply about deleting bad data. It is also about documenting why an observation was flagged as “bad” and preserving the original measurements.
A suspicious value may turn out to be an error, but it may also be the most interesting observation in the dataset. A sudden drop in a camera index could be caused by a faulty exposure, or it could correspond to mowing. Without the original observation and the surrounding context, it can be difficult to tell the difference.
Process transparently
Processing turns raw observations into usable data products. This may include radiometric conversion, geometric correction, masking, ROI extraction, aggregation, filtering, index calculation, spatial interpolation, model fitting, or uncertainty estimation. Every one of these steps changes the data in some way.
For this reason, processing should ideally be designed so that it can be rerun. I have seen workflows built around Excel sheets where values are copied from one file to another, columns are renamed manually, filters are applied by hand, and intermediate files accumulate in folders with names such as “final”, “final2”, and “final_really_final”. These workflows can work for a small dataset, but they become difficult to audit or reproduce once the project grows.
This does not mean that every analysis needs a complicated software pipeline. It means that the steps should be clear and repeatable.
Keep the original files where possible. Version code and processing settings. Document manual steps. Give derived products clear identifiers. Keep track of which processing version produced a particular result.
Reproducible processing is not only important for publication. It is also useful for the original research team. If a result looks unexpected six months later, being able to rerun the workflow and inspect each step can save a great deal of time.
Validate and interpret
Validation asks whether a derived result agrees sufficiently with independent evidence for its intended use.
For example, suppose a camera-based index is being used to estimate the timing of crop emergence. A calibration dataset might be used to develop the relationship between the image-derived signal and field observations of emergence. Validation would then test how well that relationship performs using observations that were not used to build the model. The distinction matters. A model can describe its calibration data very well without necessarily working equally well under different conditions.
Calibration establishes a relationship. Validation provides evidence about how well that relationship performs beyond the data used to establish it. Interpretation then brings the result back to the original question.
A field camera curve may show a sudden decline in greenness, but management records might reveal that the field was mown. A thermal pattern may be consistent with water stress, but weather observations and soil-moisture measurements may be needed to determine whether that interpretation is reasonable.
The more important the conclusion, the more useful it becomes to consider the sensor data alongside other evidence.
Make the result usable
The final task is to communicate what was observed, how it was processed, what uncertainty remains, and what the result can actually support.
A useful data product is not necessarily the most complicated one. It is one that is fit for purpose, traceable to its observations, and understandable to the people who need to use it.
For one project, that might be a daily time series of canopy greenness. For another, it might be a map of soil variability. It could be a warning that water levels have crossed a threshold, a dataset for a model, or simply a well-documented archive that can be analysed later. The important thing is that the connection between the final product and the original observation has not been lost.
Keep the chain intact
A proximal sensing workflow is therefore not simply a pipeline that begins with a sensor and ends with a figure. It is an observation system that begins with a question and preserves the connection between field conditions, recorded signals, derived products, and insight. The sensor is only one part of that system. The mounting position, acquisition schedule, maintenance routine, metadata, quality control, processing, reference observations, and interpretation all contribute to the final result.
Good proximal sensing is therefore not about collecting as much data as possible. It is about designing a measurement system in which the data can still make sense when we eventually ask what they mean.
Explore further:
Pierrat, Z. A., Magney, T. S., Richardson, A. D., Runkle, B. R. K., Diehl, J. L., Yang, X., et al. (2025). Proximal remote sensing: An essential tool for bridging the gap between high-resolution ecosystem monitoring and global ecology. New Phytologist, 246(2), 419–436. https://doi.org/10.1111/nph.20405
Schmidt, L., Schäfer, D., Geller, J., Lünenschloß, P., Palm, B., Rinke, K., Rebmann, C., Rode, M., and Bumberger, J. (2023). System for automated quality control (SaQC) to enable traceable and reproducible data streams in environmental science. Environmental Modelling & Software, 169, 105809. https://doi.org/10.1016/j.envsoft.2023.105809
Leave a Reply