Hi!
I’m having a problem doing anything with the copr sample dataset (which I found here - GitHub - OpenDroneMap/odm_data_copr: odm_data copr dataset)
I am loading all 41 images, as well as the gcp_list.txt file, for a total of 42 files to process. The process runs fine for the first 10 is minutes, then fails. I have tried with the default settings, as well as with lower and higher (5000 and 10000) min-num-features, and with use-pmvs on and off. However from looking at the log file the problem seems to be to do with the gcp’s somehow… Log file is in the link below, any help would be much appreciated! And sorry if this is a very newbie question!
Log file: https://drive.google.com/open?id=1pL2eb6N7DVFsB_McMKRiNMEm4vUAwaX-
Hey @Murray2015 how are you processing these images (via WebODM upload, using directly OpenDroneMap, node-OpenDroneMap, …)?
Please post the entire command you are using if you are using OpenDroneMap directly.
Hi pierotofy!
This is all via WebODM. All accepting the defaults, except the changes I said in my original post.
1 Like
This is a problem with the version of OpenSfM we’re using, which doesn’t handle well GCP files that have a trailing newline at the end. This has already been fixed, we just haven’t updated the docker images. I’ll do it by tonight, so make sure to update WebODM tomorrow via ./webodm.sh update.
A workaround for now should be to remove the last line (which is empty) in the GCP.
That update seems to have fixed that trailing line problem in the GCP file perfectly, without the workaround 
I’ve got the copr dataset running again from the defaults, let’s see how far I get this time…!
Hmm so the copr dataset gets much further now, but seems to get stuck and crash just after texturing with the line:
Error in Georef:
Error while loading point cloud: one of the property keys was not found in the header: nx
log file here: https://drive.google.com/open?id=1lXMpfEcYWQixK3XsOJGHzBDx6l4UmF13
This is still with me using all the defaults in WebODM. Am I being stupid?! I’ve gotten the Callierra, Aukerman and Bellus test dataset working just fine…
Disabling the --fast-orthophoto gets the processing a little further, but still crashes. Looks like the issue is:
PDAL: writers.las: Unable to convert scaled value (1.564621925e+25) to int32 for dimension 'Z' when writing LAS/LAZ file
Possibly an integer overflow?? (But I really don’t know enough about this to diagnose!)
log file:
https://drive.google.com/open?id=1L72IA0cBsNSrX2xk2ivhr6y0mobgrWA7
Also, I feel like I’m taking up a lot of your time @pierotofy , so sorry!
Could you share your images as well as all the options you used for processing so that we can try to reproduce this problem? Seems the same as PDAL: writers.las: Unable to convert scaled value (1.564621925e+25) to int32 for dimension 'Z' · Issue #798 · OpenDroneMap/ODM · GitHub
Sure, the images are the copr dataset from ODM’s test datasets: GitHub - OpenDroneMap/odm_data_copr: odm_data copr dataset
I’m using WebODM and uploading all images and gcp_list.txt for a total of 42 files loaded into WebODM. I’m then choosing “normal” set of options from the dropdown menu and changing no other options.
1 Like