swap NaNs for zeros

[smathermather]

Not sure if this is the appropriate approach or if we should instead be detecting NaN once read and changing them, but NaNs in GCPs seems to be a relatively common gotcha.

[pierotofy]

NaN is a valid value and part of the GCP spec. I definitely wouldn't swap them for zero: https://docs.opendronemap.org/gcp/#gcp-file-format

If you want to use zero, use zero.

[smathermather]

Do we have a sense of why NaN commonly cause failures then? I haven't explored it beyond seeing it as a fairly common failure mode.

[Saijin-Naib]

Yeah, this comes up fairly frequently in the Community as an issue.

[smathermather]

Yes, and has for at least the last 4 years, but maybe longer. It does look like we have logic that should handle this: test for a NaN, set to zero, and set has_altitude to False:
https://github.com/OpenDroneMap/OpenSfM/blob/322/opensfm/io.py#L851

Perhaps the values are not being picked up as NaN on parsing?

[smathermather]

Testing just using math.isnull instead of np.isnull here: OpenDroneMap/OpenSfM#37

I need a faster dataset for testing... .

[pierotofy]

Try to turn on --force-gps also if you have a problematic dataset.