Running WebODM has been running great until I started adding GCP. It Appears to finish Processing
Postprocessing:Done Then seem to hang for hours Compressing All.zip.
If I run the same options without GCP file it completes. Have not had this happen on any other tasks or projects using GCP,
My Operating system is Windows 10 PRO. Webodm using Docker. 16 GB Ram, Intel I7.
Looking for direction.
Thanks for any help you may provide
@VDS have you configured docker to use more memory? It’s likely that this is a problem caused by low memory.
Yes I upped the memory to 12gis, increased processors, increased swap and vd size. Still hangs.
I did change the projection format in the GCP file from
EPSG:3605 (+proj=lcc +lat_1=49 +lat_2=45 +lat_0=44.25 +lon_0=-109.5 +x_0=599999.9999976 +y_0=0 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +to_meter=0.3048 +no_defs )
to
EPSG:2256 (+proj=lcc +lat_1=49 +lat_2=45 +lat_0=44.25 +lon_0=-109.5 +x_0=599999.9999976 +y_0=0 +ellps=GRS80 +datum=NAD83 +to_meter=0.3048 +no_defs )
and it worked. The point cloud and ortho did not have the correct geo-positioning but i was able to use in in my earthwork files after a rotation. Made it work but would like to figure it out so I don’t have to repeat it again.
Thanks for any help or direction you can provide.
Mm, strange. Could you share the images and GCP file you used, as well as the preset information you used for processing? You can use Google Drive / Dropbox to share the images and GCP file.
Images and GCP Files have been uploaded to gogledrive see link below.
https://drive.google.com/open?id=1peLwR6nrGWjqDXOU198YTY_sTsaxJ7Oz
File Names:
Drone 1 Field Survey 100-105.txt (Ascii text file field survey ground control points) (MT State Plane NAD83-2007)
gcp_file_100-105.txt (Ascii text file Modified header to EPSG:2256 ((NAD83 / Montana (ft): EPSG Projection -- Spatial Reference) This on Completes but wrong geo-location for Orthophotp and point cloud but good coordinate calculation for import to CAD with no Projection)
gcp_file_EPSG3605 100-105.txt (Ascii text GCP file EPSG:3605 (((http://spatialreference.org/ref/epsg/3605/) This on Does not Complete Hangs on compressing All.zip.
Phantom 4 Pro Images (Compressed zip folder containing Images) Sorry for all the images on a small site but I have elevation restriction in the project area.
The Control point coordinates were collected by Topcon Hiper Lite survey grade. Project was localized. Horizontal and vertical error at time of field survey of GCP was less than ±0.05
Survey ground control points were exported to ascii text file and the header line was added for projection (EPSG:3605 (+proj=lcc +lat_1=49 +lat_2=45 +lat_0=44.25 +lon_0=-109.5 +x_0=599999.9999976 +y_0=0 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +to_meter=0.3048 +no_defs ) Reference website (http://spatialreference.org/ref/epsg/3605/)
Then I used the GCP WebODM interface to make the GCP file
Used Default Fast Orthophoto with resize image 2048. Did not complete processing hang at compressing all.zip 10hrs plus
Then I used Fast Orthophoto with resize image 2048 no GCP and completed 1hr 22Min.
Did some reading and changed the Header file and renamed the GCP file to gcp_file_100-105.txt Header projection changed to (EPSG:2256 +proj=lcc +lat_1=49 +lat_2=45 +lat_0=44.25 +lon_0=-109.5 +x_0=599999.9999976 +y_0=0 +ellps=GRS80 +datum=NAD83 +to_meter=0.3048 +no_defs) and it worked geo-location not good but coordinates of point cloud and ortho image insert into CAD with no projections and match other field survey data. good for today but leaves me wondering what I’m doing wrong.
Thanks for the Help
any other questions please contact me.
Once again Thanks for the Help.
Hi! I have the same problem. When i use photos from Phantom 4 Pro without GCP all is ok, but when i add GCP file WebODM not finish task. It create ‘assets’ directory of task with all products (ortophoto, pointcloud, etc.) then delete ‘assets’ directory of task and create it again with all products (ortophoto, pointcloud, etc.) then again delete ‘assets’ directory and it stuck in this infinity loop. When i cancel task the ‘assets’ directory of task with all products (ortophoto, pointcloud, etc.) is available on WebODM data directory (i use ‘–media-dir’ parameter) but it’s unavailable via WebODM interface because task status is ‘cancelled’.
I use EPSG:2178. The header of GCP file:
+proj=tmerc +lat_0=0 +lon_0=21 +k=0.999923 +x_0=7500000 +y_0=0 +ellps=GRS80 +units=m +no_defs
1 Like
Same problem, In my workflow, I place all the images and the GCP file in the same folder, the when adding, I select all the images and the GCP file. Is this correct?
It will stay like this for hours. I wouldn’t care if I could find the assets somewhere.
My GCP file: GCP’s WGS84 (EPSG 3857).txt
+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m [email protected] +wktext +no_defs
1 -10362980.952 4086086.888 133.851499634236
3 -10363000.888 4086065.784 134.205376737381
PumpStation -10362966.118 4086141.868 134.981711777615
PLStrip -10363029.45 4086100.659 135.776944647647
4 -10363082.707 4086072.045 135.972323823458
GCP file Generated from WebODM interface (the file originally wouldn’t even come close to processing, when I looked at it it appeared as if it was a combination of tab and space delimited text, I then cleaned it up a bit removing all but the spaces) I used the file in un edited and it didn’t process either.
gcp_file.txt
+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m [email protected] +wktext +no_defs
-10363082.71 4086072.04 135.972323823458 1656.60 1001.09 DSC00798.JPG 4
-10363082.71 4086072.04 135.972323823458 1978.76 2117.82 DSC00797.JPG 4
-10363082.71 4086072.04 135.972323823458 1785.17 3056.89 DSC00818.JPG 4
-10363029.45 4086100.66 135.776944647647 1516.39 2420.11 DSC00801.JPG PLStrip
-10363029.45 4086100.66 135.776944647647 1328.69 1375.16 DSC00802.JPG PLStrip
-10363029.45 4086100.66 135.776944647647 2019.32 1576.95 DSC00815.JPG PLStrip
-10362966.12 4086141.87 134.981711777615 1546.53 1729.15 DSC00807.JPG PumpStation
-10362966.12 4086141.87 134.981711777615 1880.62 2329.00 DSC00809.JPG PumpStation
-10362966.12 4086141.87 134.981711777615 1739.75 1256.57 DSC00810.JPG PumpStation
-10363000.89 4086065.78 134.205376737381 1328.11 2636.61 DSC00822.JPG 3
-10363000.89 4086065.78 134.205376737381 2467.48 2289.85 DSC00831.JPG 3
-10363000.89 4086065.78 134.205376737381 4294.02 2094.32 DSC00833.JPG 3
-10363000.89 4086065.78 134.205376737381 4142.75 1305.54 DSC00834.JPG 3
-10362980.95 4086086.89 133.851499634236 1927.19 2550.10 DSC00824.JPG 1
-10362980.95 4086086.89 133.851499634236 1772.23 1541.61 DSC00825.JPG 1
-10362980.95 4086086.89 133.851499634236 1771.94 2722.64 DSC00829.JPG 1
-10362980.95 4086086.89 133.851499634236 1752.29 1396.22 DSC00830.JPG 1
Please Help!
Mm, if you press “Cancel” and then “Restart” (important! Choose the dropdown arrow, don’t press the main “Restart” button, use the arrow button next to it) → “From Orthophoto”, are you able to get the results?
People have been reporting this problem before, but I’ve never been able to reproduce it myself. It’s puzzling.
Perhaps related to Archive hanging near the end of zipping · Issue #217 · archiverjs/node-archiver · GitHub it could be that this event is never fired. NodeODM/Task.js at master · OpenDroneMap/NodeODM · GitHub
Could everyone who’s having this problem please share the amount of RAM available on your machine / allocated to the docker environment? Perhaps this is a memory problem (eg. archiving takes up too much memory, the OS kills the web worker in charge of processing tasks → WebODM hangs).
Also please try the following:
- If a task hangs at “Compressing All.zip”, keep the hung task (do not cancel it) and create a new task (upload 2-3 images to the task) and press “Start Processing” do you get any output from the newly created task?
Thank You so much for the help! I pressed cancel then restart from ortho photo - No Joy
the clock never moved, but the process took about 7 minutes
Did you mean for us to create a new task in the same project? I didn’t see a way to do that.
First attempt new project name test
I kept the hung task and re loaded the other project that was not running with GCP file, then clicked “Start Processing” from the newly created task? 5 minutes in and same result
second attempt (name test2) without GCP file/ I left both projects (test and UPS Malvern 2) open and running, I then added only the images from the first open project (UPS Malvern 2). Success
Ok, so I panicking a little. I’m supposed to fly a 550 acre quarry next week and I getting anxious.
I was readingthis page on github and decided to try again using WGS84 for my GCP’s and naming the file exactly “gcp_list.txt”. While using the “GCP Interface” in WebODM I added my points in WGS84,
I then looked at the GCP file and I noticed the file generated by the interface had shortened the Lat/Lon to only 2 decimal places and again appeared to be using Tabs instead of spaces ad delimiters (I don’t know if the tabs make a difference, but I’m sure the Lat/Lon need more than 2 decimal places)
+proj=longlat +datum=WGS84 +no_defs
-93.09 34.43 135.972323823458 1655.87 1000.59 DSC00798.JPG 4
-93.09 34.43 135.972323823458 1977.85 2119.13 DSC00797.JPG 4
-93.09 34.43 135.972323823458 1785.70 3058.08 DSC00818.JPG 4
-93.09 34.43 135.776944647647 1516.74 2419.22 DSC00801.JPG PLStrip
-93.09 34.43 135.776944647647 1329.68 1375.76 DSC00802.JPG PLStrip
-93.09 34.43 135.776944647647 2019.79 1576.71 DSC00815.JPG PLStrip
-93.09 34.43 134.981711777615 1547.12 1729.01 DSC00807.JPG PumpStation
-93.09 34.43 134.981711777615 1882.35 2330.70 DSC00809.JPG PumpStation
-93.09 34.43 134.981711777615 1738.79 1256.34 DSC00810.JPG PumpStation
-93.09 34.43 134.205376737381 1328.27 2635.81 DSC00822.JPG 3
-93.09 34.43 134.205376737381 1098.61 604.72 DSC00824.JPG 3
-93.09 34.43 134.205376737381 2465.55 2287.95 DSC00831.JPG 3
-93.09 34.43 134.205376737381 4292.84 2094.18 DSC00833.JPG 3
-93.09 34.43 134.205376737381 4143.53 1305.02 DSC00834.JPG 3
-93.09 34.43 133.851499634236 1927.48 2551.29 DSC00824.JPG 1
-93.09 34.43 133.851499634236 1771.60 1541.38 DSC00825.JPG 1
-93.09 34.43 133.851499634236 1549.76 675.64 DSC00826.JPG 1
-93.09 34.43 133.851499634236 1772.65 2722.77 DSC00829.JPG 1
-93.09 34.43 133.851499634236 1753.19 1395.86 DSC00830.JPG 1
-93.09 34.43 133.851499634236 1772.33 248.47 DSC00831.JPG 1
(In windows note the file reads as one long file with tabs between fields, see screen shot)
 counting on WebODM to recognize and use my GCP’s
The project processed in 7 minutes, but as expected WebODM did not use any GCP’s
lastly, I used the corrected GCP file and selected it along with the images and after 6:28 I got a new error.
I’m increasing the minimum number of features from 8000 to 16000 now, I’ll post back with results
Same error heres a link to my Data, should be 40 images, and 2 GCP files, 1 exactly as it came from the webODM GCP interface and the one I edited, Thanks Again!
https://drive.google.com/drive/folders/16cogZJzThosSXG8TT8u0PM23NF6FZyP3?usp=sharing
@mwfoshee please open a new topic if this is a different issue. Thanks!! 
Either on the same project or a new project. Didn’t matter. Seems like it’s not a memory issue, since processing started it means that nothing was killed.
Seems to get stuck only with datasets including GCP files then.
Will do, I’m not sure if it’s a new topic. It appears that when the coordinate system is WGS84 this is the issue and when the CRS is anything else this is still an issue.
Opened a bug: WebODM sometimes hangs when using a GCP file · Issue #547 · OpenDroneMap/WebODM · GitHub
If someone is able to figure out a way to reliably reproduce this issue, please document it, attach your dataset, your GCP file and report as much information as possible (environment, operating system, free disk space, memory allocated, etc.). I couldn’t reproduce this with the dataset from @VDS.