Problem Using a GCP file in the Southern Hemisphere (WGS84 UTM 36S)

I really hope someone can help me.
I’m running WebODM in docker on a 64Bit machine with 12Gig RAM available in Oracle VM Virtualbox. I also expanded my Diskspace to 100 Gigs and can process 300 photos without a GCP file with ease. I have 350GIG available on my hard disk. I used a Phantom 4 Pro and dronedeploy for a 82% overlap in the flight path. Quality of images are set on highest setting (7,5MB)

My problem is:
As soon as I create a gcp_list.txt file on the “WGS84 UTM 36S” projection, I get an error after 14 minutes ( See Task Output and link to Images and gcp_list.txt file)
I also tries “WGS” with Lat long coords but get error after only 4 minutes).
Can WebODM accomodate the southern hemisphere? The project is in South Africa. I also tried EPSG:32738 on the first line without success.
The South African default projection is actually Hartbeesthoek94 WG31 degrees, but my thinking was to create a point cloud in UTM and convert coordinates to Hartbeesthoek94.

I used the default Processing Node, Default options and no-resize of images.

You can find the dropbox link for the Images, Task Output and GCP file here:

I’ve done a bit of research on the topic and will try two alternative options tomorrow:
1 Use the “EPSG: 2054” description in the first line of the gcp_lst.txt file.
2 Use Proj4 +proj=tmerc +lat_0=0 +lon_0=31 +k=1 +x_0=0 +y_0=0 +axis=wsu +ellps=WGS84 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs." String.
Hope I will have some luck!

Hey @connie102 thanks for reporting the issue!

This is a bug. Your GCP file is correct. I have created a patch to fix this problem for future versions of OpenDroneMap here: Fixed GCP UTM south region parser typo by pierotofy · Pull Request #309 · mapillary/OpenSfM · GitHub

In the meanwhile, you should use a proj4 definition as a workaround.

Thanks @pierotofy.
Proj4 UTM 36S seems to be working. I don’t get an error report like before, but it has been “running” for the last 13hours. Seems to get stuck at the Indexing calculation in the task menu. It might be my computer. I am trying a few other things before reporting an issue.
Thanks for your help!

@connie102 & @pierotofy
Was there ever a resolution?
I am also having problems very similar to described above.
I’m only running moderate 200-500 image runs (though i would ideally like to run the entire 4500 image set !)

Initially I had Issues with GCP’s being accepted in the GCP Interface. This is still a problem (i suspect a bug) but was temporarily solved by going through numerous versions of different header/data combinations and eventually finding one that works (MGAz51 proj4 in this case)

Now (as described above) the process appears to be stuck at INDEXING: 2M or 3M points processed.
Processor (and fan noise) still running at high speeds in background for >10hrs, so i am unsure whether the process has crashed or the processor is in infinite loop

  • Ubuntu 18 native install. Quad core, 8g Ram (60g swap), 100g SSD free space
    WEbodm. Default settings, no resize, dsm true/dtm true,

help appreciated.

Hey @hrdrck!

Did you have any luck fixing the problem? I’m also getting stuck at the same point.



No, unfortunately not.
however, as the projects are in Australia. I changed to GDA94/MGA (close enough to exactly the same as UTM) which did successfully run ‘some’ of them…

Good luck!

Hey @hrdrck!

Maybe it helps, maybe it doesn’t, but I was able to make it work by:

  1. Converting my Argentinian format to longitude/latitude
  2. Converting longitude/latitude to UTM

When I did that, it started working every time.