WebODM for Survey Usage

WebODM
1

I’ve been exploring ODM for survey usage for the last several weeks. I’ve been running it on a variety of cloud-based machines in Linux (AWS 2) everything from smaller end machines up to ~100 vcpu, 1TB ram. I’ve exercised single instance tasks, multi-instance different tasks run concurrently, and ClusterODM tasks run from WebODM using up to 5 machines. All with various options set. Runs on the same data set, 600+ images, varied from 2.5 hrs up to 7 hrs. The last thing to exercise was inclusion of a GCP file. With much help from the questions and answers here, I was able to get a state plane coordinate system file created, starting with a no-image file from Pix4d converted into a usable gcp_list.txt file using GCPi. One problem I have is that I’m not able to reload this gcp file back into GCPi and view my locked points. That said, when the file is brought up to load, it appears to be fine and it loads without error. Here is the original no-image file and the conversion:

+proj=tmerc +lat_0=37.5 +lon_0=-85.66666666666667 +k=0.9999666666666667 +x_0=100000 +y_0=250000 +ellps=GRS80 +datum=NAD83 +to_meter=0.3048006096012192 +no_defs
JMT50 556055.6978 1403883.6979 497.2820
JMT51 555974.4955 1404030.4520 497.5420
JMT52 556074.1074 1404095.5406 498.6550
JMT53 556165.7922 1403943.2338 497.4570
JMT54 556236.3355 1403963.3672 497.4370
JMT60 555783.8170 1404335.7854 504.6350
JMT61 555864.9984 1404066.1337 500.2800
JMT62 556383.8311 1403623.7548 496.1650
JMT63 556556.4905 1403270.6650 493.3000

+proj=tmerc +lat_0=37.5 +lon_0=-85.66666666666667 +k=0.9999666666666667 +x_0=100000 +y_0=250000 +ellps=GRS80 +datum=NAD83 +to_meter=0.3048006096012192 +no_defs
556556.49 1403270.66 493.3 3947.43 3266.22 DSC09267.JPG JMT63
556556.49 1403270.66 493.3 3962.00 3318.00 DSC09266.JPG JMT63
556556.49 1403270.66 493.3 3994.76 3401.00 DSC09265.JPG JMT63
556383.83 1403623.75 496.165 2322.99 2563.66 DSC09275.JPG JMT62
556383.83 1403623.75 496.165 100.06 4428.59 DSC09403.JPG JMT62
556383.83 1403623.75 496.165 5084.79 882.95 DSC09273.JPG JMT62
556383.83 1403623.75 496.165 3742.91 1699.07 DSC09274.JPG JMT62
556236.34 1403963.37 497.437 6906.86 2281.73 DSC09314.JPG JMT54
556236.34 1403963.37 497.437 3977.57 3414.03 DSC09338.JPG JMT54
556236.34 1403963.37 497.437 7022.37 509.45 DSC09313.JPG JMT54
556165.79 1403943.23 497.457 3515.77 3895.82 DSC09339.JPG JMT53
556165.79 1403943.23 497.457 7311.25 1899.50 DSC09313.JPG JMT53
556165.79 1403943.23 497.457 3368.31 2223.06 DSC09338.JPG JMT53
556055.70 1403883.70 497.282 2852.21 1294.86 DSC09356.JPG JMT50
556055.70 1403883.70 497.282 2897.50 3009.25 DSC09357.JPG JMT50
556055.70 1403883.70 497.282 2087.74 4107.32 DSC09340.JPG JMT50
556074.11 1404095.54 498.655 937.50 2251.25 DSC09839.JPG JMT52
556074.11 1404095.54 498.655 5148.32 2248.99 DSC09312.JPG JMT52
556074.11 1404095.54 498.655 987.50 1450.25 DSC09837.JPG JMT52
555974.50 1404030.45 497.542 6618.08 2013.35 DSC09311.JPG JMT51
555974.50 1404030.45 497.542 4247.96 3675.52 DSC09341.JPG JMT51
555974.50 1404030.45 497.542 6568.04 3735.52 DSC09312.JPG JMT51
555865.00 1404066.13 500.28 4346.95 3327.94 DSC09342.JPG JMT61
555865.00 1404066.13 500.28 4559.04 4962.74 DSC09343.JPG JMT61
555865.00 1404066.13 500.28 6444.81 2382.22 DSC09310.JPG JMT61
555783.82 1404335.79 504.635 5421.42 597.35 DSC09600.JPG JMT60
555783.82 1404335.79 504.635 5428.01 4339.72 DSC09603.JPG JMT60
555783.82 1404335.79 504.635 2427.00 3666.00 DSC09606.JPG JMT60

The conversion to this format was handled entirely by GCPi. (Along the way it dropped a couple of decimal places in my x/y coordinates.) I realize this is borderline for the survey requirements but 9 points was all I had in the test set and the overlap among images was marginal.

Second thing about this is that the GCP enabled run seems to take a bit longer, which perhaps makes sense considering the relatively few number of points.

Finally, how do I know that the GCP points were actually used? I’ve asked my survey team for a quality inspection but can I know for sure that the system used GCP rather than, for instance, EXIF data for the reconstruction? Does force-gps replace the GCP’s with EXIF data or use them in conjunction with each other?

One thing I’ve discovered in this exercise is that we’ve also run comparative tests on the same set of data with Pix4D for both cloud-based and on-prem (large machine) instances. The performance differences give me pause and make me wonder what I’m not doing with ODM that the surveyors did do with Pix4D. Do people have performance comparisons between these 2 systems?

Overall, this has been an incredible exercise with an incredible product so thanks so much to those who have contributed. My background is in machine learning so I hope to be able to contribute to the community in some way in the near future. Thank you for all the help in these exchanges - I’ve made good use of them.

Editorial addition: If anyone has the ability to automatically perform a quality check, with an accuracy metric, on the GCP’s, comparing their location in the Orthophoto to their actual registered location, that would be of interest.

5 Likes
2

Answering one of my own questions here with this doc link - https://docs.opendronemap.org/gcp.html#id1

POSM GCPi accepts a different format than it generates for ODM. Consequently, no reload capability into GCPi after transformation from labeled points to points locked to images with labels as optional descriptors.

3

If you provide a GCP file, the GCPs will be used for alignment, not the EXIFs. There’s no output during the reconstruction that will show this, however (should be added in a report, a future feature we plan to add).

--force-gps will instruct the system to use both GCPs and information from EXIFs. So it doesn’t replace, but augments (useful if you use something like RTK).

1 Like
4

I’m of no use in helping with your GCP questions, but I did want to say thanks for posting your comments here. I believe the discussions here are valuable, but it’s easy to forget and nice to get confirmation once in a while.

Also, I want to say thanks for the thorough performance analysis you are doing. If you are able to share any of your results, even a summary, I think a lot of people would find it useful. We have the benchmarks project which tries to achieve some of this, but you’ve probably taken it farther than we have. We have also focused mainly on performance, where I expect you are looking at both performance and precision. Anyway, if you are able to share something, a small summary or even a dump of raw results, we’ll figure out how to incorporate for the community.

1 Like
5

Absolutely - I hope the work we’re doing is relevant.

3 Likes
6

Thanks, that clears it up for me. My early analysis of the agreement between GCP locations and the locations shown in the resultant cloud didn’t yield much fruit. I’m using this site for conversion from the cloud locations back to state plane - http://www.earthpoint.us/StatePlane.aspx. The values were way off so more research to do on that this weekend.

If anyone has a better approach, I would be interested to hear.

7

UTM/State Plane conversions are likely to be fraught, particularly if there are datum transformations in there as well, although PROJ has come a long way in this regard, so maybe my fears are unfounded. A real limitation to OpenDroneMap at the moment is the lack of direct support for alternatives to UTM, but you might look to PDAL to do your point cloud transformations back to state plane. It should have best-in-class tranformation across projections and datums given the amount of attention that Howard Butler has given to bringing PROJ up to speed over the years.

3 Likes
8

Thanks for that tip. I am familiar with PDAL.

1 Like
9

@smathermather @pierotofy Is the rounding that occurs between the provided GCP (4 places in x,y,z) and the generated GCP (2 places in x,y and 3 in z) necessary?

10

Probably not; we’d welcome a pull request on POSM GCPi to improve this.

2 Likes
11

Great - I’ll take a look.

2 Likes