Setting GCP to NaN often results in failed processing

[smathermather]

How did you install ODM? (Docker, installer, natively, ...)?

All installation types, AFAIK. Docker for me.

What is the problem?

Setting GCP to NaN often results in failed processing. We can see this quite often on the forum:
https://community.opendronemap.org/search?q=nan%20gcp%20order%3Alatest

What should be the expected behavior? If this is a feature request, please describe in detail the changes you think should be made to the code, citing files and lines where changes should be made, if possible.

When NaN is found, it should set elevation to zero (0) and set has_altitude to False, per the code here:
https://github.com/OpenDroneMap/OpenSfM/blob/322/opensfm/io.py#L851

How can we reproduce this? What steps did you do to trigger the problem? If this is an issue with processing a dataset, YOU MUST include a copy of your dataset AND task output log, uploaded on Google Drive or Dropbox (otherwise we cannot reproduce this).

Take the Sheffield Cross dataset, set all the elevation values to NaN and then run on default:

Fused depth-maps 124 (72.09%, 507ms, ETA 196ms)...
Fused depth-maps 166 (96.51%, 609ms, ETA 22ms)...
Fused depth-maps 172 (100%, 620ms)
19:54:35 [App     ] Densifying point-cloud completed: 0 points (6m7s205ms)
19:54:35 [App     ] MEMORYINFO: {
19:54:35 [App     ] 	VmPeak:	 9803292 kB
19:54:35 [App     ] 	VmSize:	 6477456 kB
19:54:35 [App     ] } ENDINFO
[INFO]    running "/code/SuperBuild/install/bin/OpenMVS/DensifyPointCloud" --filter-point-cloud -20 -i "/var/www/data/283abb6b-8284-425c-a207-9b1f214ecaa5/opensfm/undistorted/openmvs/scene_dense.mvs" -v 0 --cuda-device -2
19:54:35 [App     ] OpenMVS x64 v2.2.0
19:54:35 [App     ] Build date: Aug 13 2024, 04:58:57
19:54:35 [App     ] CPU: QEMU Virtual CPU version 2.5+ (24 cores)
19:54:35 [App     ] RAM: 503.70GB Physical Memory 5.35GB Virtual Memory
19:54:35 [App     ] OS: Linux 6.8.0-40-generic (x86_64)
19:54:35 [App     ] Disk:
19:54:35 [App     ] warning: no AVX compatible CPU or OS detected
19:54:35 [App     ] Command line: DensifyPointCloud --filter-point-cloud -20 -i /var/www/data/283abb6b-8284-425c-a207-9b1f214ecaa5/opensfm/undistorted/openmvs/scene_dense.mvs -v 0 --cuda-device -2
19:54:35 [App     ] error: no valid point-cloud for the ROI estimation
Segmentation fault (core dumped)

===== Dumping Info for Geeks (developers need this to fix bugs) =====
Child returned 139
Traceback (most recent call last):
File "/code/stages/odm_app.py", line 82, in execute
self.first_stage.run()
File "/code/opendm/types.py", line 470, in run
self.next_stage.run(outputs)
File "/code/opendm/types.py", line 470, in run
self.next_stage.run(outputs)
File "/code/opendm/types.py", line 470, in run
self.next_stage.run(outputs)
[Previous line repeated 1 more time]
File "/code/opendm/types.py", line 449, in run
self.process(self.args, outputs)
File "/code/stages/openmvs.py", line 230, in process
raise e
File "/code/stages/openmvs.py", line 224, in process
system.run('"%s" %s' % (context.omvs_densify_path, ' '.join(config + gpu_config + extra_config)))
File "/code/opendm/system.py", line 112, in run
raise SubprocessException("Child returned {}".format(retcode), retcode)
opendm.system.SubprocessException: Child returned 139

===== Done, human-readable information to follow... =====

[ERROR]   Uh oh! Processing stopped because of strange values in the reconstruction. This is often a sign that the input data has some issues or the software cannot deal with it. Have you followed best practices for data acquisition? See https://docs.opendronemap.org/flying/

Duplicated in OpenDroneMap/ODM#1796