Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

swap NaNs for zeros #1795

Closed

Conversation

smathermather
Copy link
Contributor

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.

@smathermather smathermather marked this pull request as ready for review August 16, 2024 15:26
@pierotofy
Copy link
Member

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
Copy link
Contributor Author

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
Copy link
Contributor

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

@smathermather
Copy link
Contributor Author

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
Copy link
Contributor Author

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

I need a faster dataset for testing... .

@pierotofy
Copy link
Member

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants