This is a known issue found in corridor projects, which our developers are still investigating.
See the illustration of the drift below.
The difference in results is not due to the platform on which you processed the project (Desktop/Cloud), but to the workflow you used to incorporate the ground control points (GCPs):
- If incorporated before step 1, GCPs are only taken into account at the very end of step 1 which prevents them from applying stronger constraints than the image geotags (if there are any). As a consequence, they are not too strongly weighted and the project is not completely fitted to their position.
- On the contrary, during the reoptimization, GCPs apply a stronger constraint on the georeferencing of the project and the project is fitted to the GCP positions. In this case, there is no shift between initial and computed GCP positions.
When processing locally, there was no shift in the position of the GCPs in the Desktop project, because you added the GCPs after running step 1 then reoptimized. In the case of the Cloud instead, there was a shift between initial and computed GCP positions since, after adding GCPs and uploading to the Cloud, step 1 started again incorporating GCPs from the beginning (processing always starts from the beginning on Pix4D Cloud).
For corridor projects, I recommend you do the following:
- Process the projects entirely on the Desktop.
- Process the project partly on the Cloud following these instructions:
- Process step 1 on the Desktop
- Add GCPs on the Desktop
- Reoptimize on the Desktop
Upload to the Cloud, where step 1 will be processed again.