Twisted road. Point cloud do no respect GCPs

[MiguelToril]

Hello everyone!

Here I present my case. This is a 5 km road which has been scanned using Zenmse P1 Camera, with 90% overlap, 8m/s speed and Nadir angle.

After running STEP 1, the output is VERY extrange. The flight began in the south of the road and the first meters are OK, but after some distance, the road starts to be twisted ending in almost complete vertical position. You can clearly see how PIX4D does not respect the orientation of the camera, despite the internal parameters have been selected as “All prior”.

See pictures atteched for better understanding.

How is it possible that the software deviates so much the angles of the camera from the original internal data. I can confirm that all pictures all well georreferenced and EXIF data contain the correct angles.

Furthermore, the project includes GCP points which I loaded into the project after running STEP 1. As expected those GCPs deviate quite a lot from the Point Cloud (or the other way around, the STEP 1 Point Cloud is quite off from where it should be).

To “help” the project to find the right 3D position I have manually created some 3D points giving those points the correct GPS coordinates. After reoptimizing the project, how is it possible that PIX4D keeps saying there is a difference between the correct position and the position calculated by itself? See picture below.

There must be something that is priorising the calculated position above the real GCP position. But I don’t find what it is.

Any ideas?

Thanks everyone in advance.

[Andrew_Milanes]

You will need at least three flight lines in order to calculate correct image orientation using photogrammetry. A single flight line for corridor mapping simply won’t work. You will need to re-fly the project.

[Rosana_Lin]

Hi Miguel,

It’s like Andrew said, one flight line does not allow photogrammetry software to find the missing overlap that’s either on the side or the front of the images. On top of this, the recommended overlap is at least 75% frontal overlap (with respect to the flight direction) and at least 60% side overlap (between flying tracks).

I recommend going through this article about image acquisition.

Image acquisition

If you have questions while reading the article, always feel free to ask!

Best regards,
Rosana (she/her)

[MiguelToril]

Thank you @Andrew_Milanes and @Rosana_Lin for you answers.

In order to test different flying/processing ways, I actually flew not just as a single corridor but with three different lines; as you can see in the picture here below.

Nevertheless I have to agree only partially with you, as I am still experiencing some issues in relation with the GCPs.

As I understand PIx4D Mapper, the software should give absolutely priority to the GCPs, am I right? It means to me that, a certain GCP with specific X,Y,Z coordinates should be respected by the software as “absolute coordinates” with zero error (yes, actually the GPS error has also some uncertainty, but let’s consider it is not relevant for the case).

Here I share with some data about a specific GCP (Nr. 15 in my project).

First of all, the point is -in my opinion- well marked and well referenced in the point cloud; 33 pictures that include that GCP and as you can see, the images have enough quality to mark the point with much uncertainty.

A relevant information for me is the estimated mistake (4,5 meters in Z). Can you please confirm me what does “Posición calculada” (Calculated position) is? Initial position is clear for me, it matches the GCP coordinates. And, calculated position should be the position estimated by PIX4D that depends of course on the pictures metadata.

Of course I am asking myself if the metadata are good enough (aka, is the Drone GPS measuring right, despite being using RTK corrections?).

But it is not the first time the data differ quite a lot and PIX4D corrects the position following the GCPs coordinates.

If I analyse the same point after orthomosaic, I and see again that on X,Y the point differs also quite a lot from where it should be. Here a screenshot from the same point on QGIS.

The GCP marked in green also shows the Z coordinate of it. So, not only differs quite a lot on X,Y but also that point (with 312,28m Z coordinate) is positioned between 313,0m and 313,2m contour lines, which makes absolutely no sense.

I could include some more examples of the same project, showing very similar mistakes, however I don’t want to make this post much longer.

Here then my, still, “big question”: how is possible that PIX4D does not respect those relevant data or in other words, what is PIX4D prioritising on top of the GCPs to end having those big deviations?

[Heydi_Contreras]

Hi @MiguelToril,

Please could you share here the last quality report that was generated by PIX4Dmapper after processing.?
Did you have tried to process by choosing “accurate geolocation and orientation” as the calibration method?

I think this option can help in this case.

Best regards,

[MiguelToril]

Hello @Heydi_Contreras;

thank you for your answer. Here I send you the report.
20220930_NIV_v1_EyO_GCP_report.pdf (692.8 KB)

Regarding the second question: yes, we have processed this project selecting “accurate geolocation and orientation” and it has not provided better results.

Any nee feedback is welcomed!

Regards!

[Mike_K]

Your project is getting better but I would take a closer look at how you marked your GCPs. Ideally, you want to keep your Projection error below 1. You have many GCPs that are above and one that is at 18.96! This tells me that the images are not marked very well. I would suggest remarking your GCPs in only 10-15 images that are of the best quality. I would zoom into the highest extent possible to ensure you are marking the exact center of the target.