Unable to connect data in multispan bridge

I am attempting to generate a point cloud around a bridge. Because the bridge deck is fairly low, it was necessary to fly through the spans (under the bridge) to collect data under the bridge with multiple paths through each span. In some isolated cases this worked okay. See Image1

My problem is that I am having problems connecting the data from different spans. One problem is probably from the lighting conditions changing as the drone moves through the span. I suspect the other problem is that the images taken in one span cannot overlap with those in the adjacent span due to the pier walls. As a result, everything seems disjointed and confused (See Image2). This image is based on over 1500 images using WebODM default settings. I have tried customizing the settings without success. We are using a Phantom4 with its standard camera settings and GCPs on the downstream side of the bridge show as shown in green in [Image3].

Any suggestions would be appreciated.

1 Like

Can you post camera positions over an orthophoto, and perhaps also with the point cloud, although given the disjointed result, the latter may not be super useful.

I’d approach it by flying vertically with changing camera angle, starting high enough to cover the GCPs, with nadir, then bring the camera up towards say -20° as you fly lower towards the ground. Do this for each separate ‘tunnel’ between the piers, making sure there is enough overlap to tie it all together with the under-bridge photos.

Best done on a light overcast day to avoid the large dynamic range encountered between full sun and heavy shade, which can make matching a bit difficult.

1 Like

Thanks for your advice.

I am posting some images showing the camera positions for 200 consecutive photos as you requested:

Image4 - Point Cloud with cameras from above
Image 5 - Same as 4 with some transparency to show hidden cameras “below the ground”
Image 6 - Point cloud viewed from the side showing the cameras in the foreground pointing up at the ground. Clearly this is an error in processing since all photos taken were taken + or - 45 degrees from nadir.
Image 7 - Orthophoto with cameras

Since flying under the bridge will cause the drone GPS quality to be poor and I don’t see any camera angle info in the Metadata of the photos, I assume that WebOBM is creating these strange position s and angles for the cameras based on errors in its processing. Do you think that using more GCPs (maybe one each side of the bridge for each span) help with this GPS issue? Alternatively, do you think using the RTK Phantom would help?

1 Like

I’d skip the ortho, I suspect it’s going to give weird results no matter what you do.

2 thoughts on the GCPs:

1: it might be worth reprocessing without them altogether to see if that improves things

2: yes having them on both sides of the bridge would probably help, and maybe you could generate some under the bridge as well, by interpolation between the ones where you have plenty of satellites in view. Using a tap measure I think you should be able to place some targets to include in your under-bridge imaging with errors of no more than a few cm.

RTK may help if you can keep the base in view… or maybe not, I don’t know enough about it

1 Like


After looking some more at the camera positions, I have concluded that the GPS coordinates in the Meta data of the images is wacky. See Image8 showing the original camera coordinates as drawn in DroneDB. Rather than proceeding from one side of the bridge to the other as the drone was flown, the coordinates seems to show the drone turning around half way through the bridge. While WebODM was able to properly connect the images (with some tweaking of the settings) and shows the cameras positions in a straight line, they appear wrong having only extended part way through the bridge as shown in Image9 and Image 10.

I thought that maybe removing the wrong coordinates from the images altogether might help so I resaved all the images as PNGs without coordinates, but WebODM was not able to process. It appears that it is still looking for GPS Info (DOP) - see Image11. I thought that GPS data in the Image Meta data was optional for processing. Is there a simple way to let WebODM to ignore GPS information on the photos?

1 Like

GPS info is optional, this is what I see with non-georeferenced photos taken with my phone

[INFO] No GPS information, using BOW matching by default (you can override this by setting --matcher-type explicitly)
[WARNING] Using BOW matching, will use HAHOG feature type, not SIFT

What error did you see with the .png images?


The error from using the default settings with my PNG is shown in Image 11 of the prior email : “Cannot process dataset” and within the detailed messages: “KeyError: ‘gps_dop’”.

I tried using BOW matching works to resolve the issue as does using the “pc-rectify = true”; however, in all cases, only a portion of the pier wall is shown.

We will retry the flight using your suggestions (and possibly with RTK) to see if we can get better results.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.