Hmm, it now completes instead of failing, but:

GNSS is really poor for that dataset, which is probably why it has GCPs. Switching testing to the dataset posted here:
https://community.opendronemap.org/t/error-processing-stopped-because-of-strange-values-in-the-reconstruction/21309

I wouldn't use count on the reliability of the GCPs in sheffield park, I remember I used a pretty cheap device for capturing points.

😆 -- fair, though I think they're better than the drone positions.

I was hoping to use Sheffield Park for the speed of testing, but alas. Will revert to the (latest) original problem dataset and see where we get. Sadly, my fast machine is my machine with only 32GB RAM, so slow machine it it.

This is a deeper problem than this pull request can address: in the absence of Z, OpenSfM regularly fails in correctly guessing the orientation of the model / minimizing error with respect to rotation. The reason setting values to 0 works so well is it forces the model into something (typically) approaching the relatively even elevations across most folks scene. But doing so by default isn't (as Piero previously mentioned) the appropriate approach.

Until we can munge OpenMVS to handling model orientation better than it does, this will continue to be a problem.