Referencing models with GCP is a great start, and if the GCPs are the exact same positions for both datasets, that is even better. To reiterate what I think your question is, you want to know 1) are GCPs enough for registering two datasets for topographic change detection, and if not, 2) is automated registration a better option for reducing error.

To make this decision, we need to know about GCP coordinate accuracy and the distribution and number of GCP. I will note that when I say coordinate accuracy, I refer to the accuracy of the instrument, such as GPS or total station, and not the accuracy reported within a photogrammetric project. If you have a lot of points (>10) and they are well distributed through your area of interest and your coordinate accuracy is high (~3 cm), then GCP is probably sufficient. If not, it may still be sufficient, you just need to test it with alignment for areas that likely have not have changed (invariant or pseudo-invariant points) or adjust you accepted minimum detectable change threshold - sometimes defined as the propagated error of your GCP (SQRT(error1^2+error2^2).

This error can be improved with automated registration, like the cloudcompare fine registration tool, but it can also exaggerate errors while telling you that registration improved. From personal experience, there can be some topographic distortion from photogrammetric datasets, especially if GCP are not well dispersed within your area of interest. This distortion will make automated registration adjust your clouds to have lower (improved) RMSE while giving them a poorer registration for change detection.

A good test for any registration is to look for apparent spatial trends in your data using a cloud to cloud comparisons. For example, in cloudcompare, run a cloud to cloud comparison and use the slider bar in the properties to look for patterns of vertical offsets. Recently I had one that showed the center of my area of interest had the lowest vertical offset and the amount of vertical offset increased as I moved away from the center. My options are to rebuild the cloud, choose a spot within the cloud that I want to focus change detection on or raise my accepted minimum detection threshold.

If you use an automated registration to improve registration error (I do this frequently), it is a good idea to do it on a subset of your data that you expect to have not changed during the detection interval. That will give you more confidence that you are not "over fitting" your point cloud, or trying to reduce RMSE at the cost of reducing topographic change where it has actually taken place. In cloudcompare you can test the original registration this way by unchecking the rotation boxes and set the drop down box to "Z". In general the cloud will not move, but will give you the same RMSE estimation. You can use that value to see if allowing rotation and translation improves RMSE significantly (as defined by you).

Thank you very much for your answer, Joshua J Caster. It is very comprehensive and above all raises some considerations.

Considering that the GCPs can be considered accurate and well-distributed (~ 2 cm and >20), and given that in the case of processing UAV data, as a rule, the GCPs are used in the Bundle Block Adjustment processes to optimize the computations, from which they clearly also inherit a absolute external orientation. In the processing of TLS data instead, the same GCPs are used as points of collimation between the various scans, inheriting in the same way the absolute external orientation.

Both in a comparison between clouds obtained from UAV, and in a comparison between clouds from UAV and TLS, I thought it was necessary only that these should had the same georeferencing in fixed points to be able to detect changes over time. As you suggested, actually performing a subsequent automatic registration, even if done on points deemed to be fixed, influences the results of the final change detection. Surely it will be an effect due to the topographical adaptation and therefore to the distortions caused in order to reduce the RMS value. But then could this topographical adaptation falsify the final results of change detection?

I think it is a good suggestion to first test any differences from the cloud-to-cloud comparison right on the GCPs to detect any offsets / systematic errors. Do you think setting a threshold equal to the accuracy of GCPs is a good idea for ignore the resulting offsets or not? In the event that these are not negligible, it will certainly be an excellent solution test the original registration deselecting the rotation boxes and setting the drop down box to "Z", as suggested by you, and then evaluate the final RMSE.

Having to detect variations that tend to be of an order equal to the accuracy of the GCPs, I will try to evaluate a minimum detectable variation threshold in order to comply with the propagation of errors on the GCPs. Can you suggest me any literature about it?

First, here are some references to accounting for elevation uncertainty estimations and propagated error. The classic one is from Lane et al. (2003; DOI: 10.1002/esp.483) that discusses a probabilistic approach to estimating propagated error. If you don't have access to online journals, this USGS publication provides a reference for simple error modeling using the square root of summed squares equation ( https://pubs.usgs.gov/sir/2009/5116/sir2009-5116.pdf ). Brian Collins at the USGS uses this in several accessible publications.

If you want to get deeper into the issue beyond minimum change detection thresholds, Joe Wheaton has nice system for spatially evaluating error that follows with these papers ( http://etalweb.joewheaton.org.s3-us-west-2.amazonaws.com/Downloads/Wheaton_etal_ESPL_DoD.pdf Article Error modeling of DEMs from topographic surveys of rivers us...

If you were using these data to make digital elevation models for raster change detection you might be interested in this tool by Wheaton: http://gcd.riverscapes.xyz/

The M3C2 plugin in cloudcompare follows a similar approach for point clouds, though photogrammetric clouds are different than lidar, so additional considerations are necessary. Rebecca Rossi adapted this approach for SFM in her graduate work ( https://pdfs.semanticscholar.org/dc83/f4d6ee92dd0270dba0a3defc7cf21dbbb979.pdf ).

To reiterate your description: You have 20 GCPs that are the same between two survey periods. Those GCPs were surveyed in with an instrument that had an accuracy of around 2cm. The GCPs were used for terrestrial lidar and drone photogrammetry (assuming SFM) in one time period and only drone SFM in another time period. You are comparing the results between UAV-UAV and TLS-UAV.

With 20 dispersed points that co-occur in both datasets and a survey accuracy around 2 cm, you can easily justify that your data is well registered. Except out of intellectual curiosity, I would not try to further register the data with an automated approach. It only complicates your methods descriptions and introduces the potential for model over fitting. As I said, the automated approach could either improve registration or exaggerate errors. If you are confident with your geo-referenced clouds, then there is no reason to risk it. If your description matches my interpretation of it, this will easily pass a peer review.

As far as systematic offsets in GCPs, I would probably account for those before you use the GCPs to geo-reference the point clouds...unless you only surveyed the GCPs in one time period and used the same coordinates in the second survey. Either way, I might question offsets that are greater than your GCP survey instrument accuracy. Larger offsets could mean that the accuracy is lower than reported. If so, the GCP coordinate accuracy should be adjusted accordingly. One alternative is to use the lowest rather than the average GCP accuracy to be conservative.

An additional note about TLS error estimations that you will see in the USGS reference by Collins above. We incorporate scan to scan registration in the error model, or how well each scan position fits together within the same survey.

I am not aware that there is an equivalent of scan to scan registration yet for SFM, but I have proposed that it could be the camera position reconstruction after three different bundle adjustment scenarios. Essentially 1.) do the full processing steps for an SFM cloud, export the coordinates of the cameras and the dense point cloud. 2) Then do the processing steps two other times to generate coordinates of the same cameras. 3) Use the standard deviation of the mean difference between the x,y and z coordinates as your "camera reconstruction accuracy."

I had no doubts about your availability, Joshua J Caster. I thank you once again for all these suggestions, they will certainly be of considerable help. I will carry out the tests adopting these your proposals and in the meantime I deepen the question with the literature you advised. Let's keep up to date.

Mirko Saponaro Besides the CloudCompare - Align tool there is an automatic fine-registration tool as well which makes possible to transform your aligned point cloud to another one which considered to be the reference one. I have a project about slowly moving sand dunes, surveying them each year, nearly in the same period of the year by an UAV. On the field I use GCPs with ~2-3 cm accuracy for each survey (it's not a large area), process each year images with SfM and in CloudCompare I fine-register at first the point clouds then M3C2 plugin is used to compute differences.

Hi János Mészáros, thanks for the intervention. Do you mean the Fine Registration ICP tool? I had also gone into this useful algorithm, but I believe that this way of co-registration imposes untruthful distortions on the cloud. Taking up the explanations of Joshua J Caster, the Fine Registration ICP would do nothing but help us in automatically identifying points on which to base the transformations.

Lately I have performed some comparison tests and actually a prior georeferencing of the clouds in the same GCPs allows to obtain more reliable results. In the study scenario we are evaluating the displacements of coastal cliffs subject to erosion and collapse: the use of a reference cloud and aligning the rest to the latter, gave inconsistent results precisely in those points where the rocky ridges were moved or they had collapsed over time.

Have you ever tested the differences between the two types discussed in your case study?

Another option besides the already mentioned approaches might be to already match the images from different timestamps during SfM processing, i.e. aligning all images at once and subsequently separate the oriented cameras again according their timestamp for dense matching. Thereby, it would be sufficient to use the GCPs of only one of the campaigns/timestamps. And it would further have the advantage that systematic errors (common in SfM) might be spatially consistent over time (as tie points are matched over several timestamps) and therefore might be negligible for change detection. However, you still need stable areas within the scenery for successful matching. Thus, the approach is not working if the entire observed area is changing. Please, see the following papers for more detailed information about time-SIFT and error behavior in SfM photogrammetry: James et al. (2017) 3-D uncertainty-based topographic change detection with structure-from-motion photogrammetry: precision maps for ground control and directly georeferenced surveys, Earth Surf. Proc. Landforms, doi:10.1002/esp.4125 Cook, K., Dietze, M. (2019) Short Communication: A simple workflow for robust low-cost UAV-derived change detection without ground control points. Earth Surface Dynamics. Feurer, D. and Vinatier, F. (2018) Joining multi-epoch archival aerial im-ages in a single SfM block allows 3-D change detection with almost exclusively image information, ISPRS J. Photogramm., 146, 495–506, https://doi.org/10.1016/j.isprsjprs.2018.10.016

Thank you very much Anette Eltner for your contribution. This is a very interesting process and I will certainly go deeper into the topic of time-SIFT.

Considering that a good percentage of the observed area is not subject to major changes, isn't there a risk of overloading the SW/HW system in a single SfM-process chain compared to several parallel chains?

Indeed, the Hardware and Software requirements increase significantly with the number of epochs you want co-register. Thus, it is important to consider prior alignment, which timestamps you want to compare.

As for the co-registration of the multi-temporal survey, in this paper:

HOW DOES CO-REGISTRATION AFFECT GEOMORPHIC CHANGE ESTIMATES IN MULTI-TEMPORAL SURVEYS?

https://www.tandfonline.com/eprint/EXNM72PP4JZY67D3T3MG/full?target=10.1080/15481603.2020.1763048

We tested various co-registration methods (including CloudCompare tools) to align multi-temporal point clouds in a topographically complex and rugged environment. We exploited a mathematical model (GPA-ICP) to co-register simultaneously a generic number of point clouds, providing a global roto-translation transformation for each survey and solving the problem of the reference survey choice in the traditional co-registration process.

Moreover, to correct the possible small inaccuracies generated from the gridding interpolation process, a custom-developed DTM co-registration tool (GRD-CoReg: (https://gitlab.com/hydrolab_uniud) was tested to align gridded data.

Hi Sara Cucchiaro, thank you so much for your suggestion. I really think it'll be useful.

Hi everyone,

regarding the discussion on this question posed some time ago, I would like to propose you to read our new work:

INFLUENCE OF CO-ALIGNMENT PROCEDURES ON THE CO-REGISTRATION ACCURACY OF MULTI-EPOCH SFM POINTS CLOUDS

https://www.researchgate.net/publication/352809897_INFLUENCE_OF_CO-ALIGNMENT_PROCEDURES_ON_THE_CO-REGISTRATION_ACCURACY_OF_MULTI-EPOCH_SFM_POINTS_CLOUDS

Curious about your considerations.

Best regards!