Georeferencing Failure with external GPS data and split-merge

[djpetti]

I’m trying to process a large-ish (~1500 images) dataset to obtain a high-quality orthophoto. The images are all geo-referenced using an external RTK GPS. I am feeding those positions into ODM using a geo.txt file and running with --force-gps. Because the dataset is large, I am also splitting it into 400-image chunks.

The initial processing (pre-split) seems to work fine, and ODM informs me that it can find and use my provided georeferencing information:

[INFO]    Running dataset stage                                                                                                                                                                     │[email protected] submodels$ ls
[INFO]    Loading dataset from: /scratch/djp44210/odm_jeevan_field/2021-11-01_m100_5502815/images
[INFO]    Loading 1584 images                                                                                                                                                                        │[email protected] submodels$ cd submodel_0001/
[INFO]    Found image geolocation file                                                                                                                                                                   │[email protected] submodel_0001$ ls
[INFO]    Parsing SRS header: EPSG:4326
[INFO]    Updated 1584 image positions

However, when it starts processing the submodels, it suddenly decides that it can’t find GPS info:

[INFO]    ==============
[INFO]    Running dataset stage
[INFO]    Loading dataset from: /scratch/djp44210/odm_jeevan_field/2021-11-01_m100_5502815/submodels/submodel_0003/images
[INFO]    Loading 579 images
[INFO]    Wrote images database: /scratch/djp44210/odm_jeevan_field/2021-11-01_m100_5502815/submodels/submodel_0003/images.json
[INFO]    Found 579 usable images
[WARNING] GPS position not available for P1780488.JPG
[WARNING] GPS position not available for P1780838.JPG
[WARNING] GPS position not available for P1790201.JPG
[WARNING] GPS position not available for P1780040.JPG
[WARNING] GPS position not available for P1780059.JPG
[WARNING] GPS position not available for P1780390.JPG
[WARNING] GPS position not available for P1780379.JPG
...

And, this then leads it to fail to produce any orthophoto at all:

[INFO]    running lasmerge -i /scratch/djp44210/odm_jeevan_field/2021-11-01_m100_5502815/submodels/submodel_0001/odm_georeferencing/odm_georeferenced_model.laz /scratch/djp44210/odm_jeevan_field/2021-11-01_m100_5502815/submodels/submodel_0003/odm_georeferencing/odm_georeferenced_model.laz /scratch/djp44210/odm_jeevan_field/2021-11-01_m100_5502815/submodels/submodel_0002/odm_georeferencing/odm_georeferenced_model.laz /scratch/djp44210/odm_jeevan_field/2021-11-01_m100_5502815/submodels/submodel_0000/odm_georeferencing/odm_georeferenced_model.laz -o "/scratch/djp44210/odm_jeevan_field/2021-11-01_m100_5502815/odm_georeferencing/odm_georeferenced_model.laz"
[WARNING] Missing /scratch/djp44210/odm_jeevan_field/2021-11-01_m100_5502815/submodels/submodel_0001/odm_georeferencing/odm_georeferenced_model.bounds.gpkg from submodel submodel_0001
[WARNING] Missing /scratch/djp44210/odm_jeevan_field/2021-11-01_m100_5502815/submodels/submodel_0003/odm_georeferencing/odm_georeferenced_model.bounds.gpkg from submodel submodel_0003
[WARNING] Missing /scratch/djp44210/odm_jeevan_field/2021-11-01_m100_5502815/submodels/submodel_0002/odm_georeferencing/odm_georeferenced_model.bounds.gpkg from submodel submodel_0002
[WARNING] Missing /scratch/djp44210/odm_jeevan_field/2021-11-01_m100_5502815/submodels/submodel_0000/odm_georeferencing/odm_georeferenced_model.bounds.gpkg from submodel submodel_0000
[INFO]    Merging all crop bounds: []
[WARNING] No bounds found for any submodel.
[WARNING] Missing /scratch/djp44210/odm_jeevan_field/2021-11-01_m100_5502815/submodels/submodel_0001/odm_orthophoto/odm_orthophoto_feathered.tif from submodel submodel_0001
[WARNING] Missing /scratch/djp44210/odm_jeevan_field/2021-11-01_m100_5502815/submodels/submodel_0001/odm_orthophoto/odm_orthophoto_cut.tif from submodel submodel_0001
[WARNING] Missing /scratch/djp44210/odm_jeevan_field/2021-11-01_m100_5502815/submodels/submodel_0003/odm_orthophoto/odm_orthophoto_feathered.tif from submodel submodel_0003
[WARNING] Missing /scratch/djp44210/odm_jeevan_field/2021-11-01_m100_5502815/submodels/submodel_0003/odm_orthophoto/odm_orthophoto_cut.tif from submodel submodel_0003
[WARNING] Missing /scratch/djp44210/odm_jeevan_field/2021-11-01_m100_5502815/submodels/submodel_0002/odm_orthophoto/odm_orthophoto_feathered.tif from submodel submodel_0002
[WARNING] Missing /scratch/djp44210/odm_jeevan_field/2021-11-01_m100_5502815/submodels/submodel_0002/odm_orthophoto/odm_orthophoto_cut.tif from submodel submodel_0002
[WARNING] Missing /scratch/djp44210/odm_jeevan_field/2021-11-01_m100_5502815/submodels/submodel_0000/odm_orthophoto/odm_orthophoto_feathered.tif from submodel submodel_0000
[WARNING] Missing /scratch/djp44210/odm_jeevan_field/2021-11-01_m100_5502815/submodels/submodel_0000/odm_orthophoto/odm_orthophoto_cut.tif from submodel submodel_0000
[WARNING] No orthophoto/cutline pairs were found in any of the submodels. No orthophoto will be generated.

I noticed that when creating the submodels, it doesn’t actually seem to copy the geo.txt file from the root directory to the submodel directory. I wonder, is fixing this as simple as copying that file?

Unfortunately, I’m not authorized to publicly share the dataset that I’m processing.

These are the options I'm using for ODM.

--project-path ${PROJECT_DIR} \
  --max-concurrency 32 \
  --orthophoto-resolution 0.23 \
  --fast-orthophoto \
  --skip-3dmodel \
  --matcher-distance 30 \
  --split 400 \
  --split-overlap 10 \
  --texturing-skip-local-seam-leveling \
  --orthophoto-compression JPEG \
  --crop 0.0 \
  --copy-to ${WORK_DIR}/${PROJECT_NAME}/${DATASET_NAME} \
  --force-gps \

geo.txt
ODM Log

[pierotofy]

This might be a bug; could you open a bug report on Issues · OpenDroneMap/ODM · GitHub ?

[Saijin_Naib]

Hmm…

It doesn’t seem you’re using GCPs, right?

Can you try running without --force-gps? I’ve never used --force-gps with a geo.txt file, and I’m not sure they interact well.

[djpetti]

To me, the documentation for --force-gps implies that you should use it if you have high-precision GPS data, but I guess since I have no GCPs, it shouldn’t make a difference…

I will try it without the flag.

[Saijin_Naib]

Ah, yeah, but it’s referring to that being in the EXIF metadata in the images, where in this case, it seems you either have no EXIF or you’re over-riding it with the data in the gps.txt.

[djpetti]

That is correct, there is no EXIF location data in these images.

ODM is still running, I will let you know if this turns out to fix the problem.

[djpetti]

Hmm, it seems this has the same problem unfortunately: no orthophoto generated, and almost identical output.

[Saijin_Naib]

Sorry to hear that!

It may indeed be a bug as Piero suggested.

Will you be able to share this dataset for debugging?

[djpetti]

The plot thickens…

I manually copied the geo.txt file to each of the submodel folders, and it worked. It produced a correctly-georeferenced orthophoto that looks pretty good. So, I guess that would suggest that this is a bug. In light of that, I will re-post this as an issue on Github.

I will also ask my supervisor if we can publicly release the data that I’m processing.

[smathermather]

Woah. Yeah, that sounds like a bug that misses the integration needed between split merge and geo files.

It is probably an opensfm bug, but go ahead and open it on the ODM repo, and we’ll let it escalate from there.

[pierotofy]

This has been fixed with GPU-enabled Point Cloud Densification (OpenMVS) by pierotofy · Pull Request #1362 · OpenDroneMap/ODM · GitHub and will be available at the next release (soon!)