Task runs without GCP file but fails with it


#1

The only difference between the two tasks is that one has a gcp_file.txt. Docs says proj4 strings will work. Any suggestions are appreciated. I’m guessing I could just convert the GCPs to WGS84/latlon, but shouldn’t this work?

proj4 string is from here: https://epsg.io/2259 (it is on a single line in the actual file)

+proj=tmerc +lat_0=31 +lon_0=-107.8333333333333 +k=0.999916667 +x_0=830000.0001016001 +y_0=0 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=us-ft +no_defs
2498401.726 1641155.270 6631.387 1880 1189 DJI_0719.JPG
2498401.726 1641155.270 6631.387 1387 1236 DJI_0723.JPG
2498401.726 1641155.270 6631.387 1444 1918 DJI_0725.JPG
2498538.775 1641147.778 6605.987 2188 1071 DJI_0633.JPG
2498538.775 1641147.778 6605.987 2240 2106 DJI_0636.JPG
2498538.775 1641147.778 6605.987 2212 1720 DJI_0670.JPG
2498716.652 1641124.304 6632.812 1868 592 DJI_0549.JPG
2498716.652 1641124.304 6632.812 1440 1106 DJI_0587.JPG
2498716.652 1641124.304 6632.812 1491 1886 DJI_0589.JPG
2498612.533 1641286.562 6633.222 2461 499 DJI_0557.JPG
2498612.533 1641286.562 6633.222 2467 2111 DJI_0561.JPG
2498612.533 1641286.562 6633.222 919 1610 DJI_0580.JPG

It fails on smvsrecon.
Surface Status - Valid patches: 660
Removed 660 patches due to occlusions.


#2

We need to improve support for GCP files (both documentation wise and functionality wise).

If you use a UTM projection for the GCP coordinates, do you get better results?


#3

Converted to UTM last night, re-ran it, and it was completed this morning. But you can see that the GCPs are not exactly on the spot.

It detected that the area was WGS1984 UTM Zone 12, so I used that coord system for the GCPs. (Which were collected with a Trimble GeoXH.) Shouldn’t the GCP coords match even if they were off due to GPS inaccuracies? All of the points are off by a few feet. I rechecked the pixel locations for the images and all are correct. Would using an EPSG code yield better results?

Coord sys in gcp file: +proj=utm +zone=12 +ellps=WGS84 +datum=WGS84 +units=m +no_defs

Without the GCPs, the image was simply shifted to the East a consistent 8ft for all GCPs.

Capture


Improvement of Absolute Accuracy by processing images together with gcp_list.txt file
#4

Perhaps check that you are converting your coordinates properly? https://gis.stackexchange.com/questions/133861/converting-between-wgs84-and-nad83

I’m not sure this is the root problem, but perhaps it is.


#5

Well, I guess technically it was in WGS84 from the beginning as it came straight off of the GPS receiver, right? So no datum conversion. I converted to State Plane the first time and used a proj4 string for that State Plane system, which didn’t work anyway. This time I used the string from the odm_georeferencing file created with no gcp file.

But even if it wasn’t correct, shouldn’t the ground marker in the ortho image match the point? It would be skewed/stretched elsewhere in the image, but they would be top of each other.

Interestingly, I reran it again with higher precisions on the offsets for the images (three decimals) and it was better. (I used a blank/empty ArcMap.) Thanks for your help.


#6

You’re right, the markers should still match on the ortho.

I’ve been running some tests with GCPs this afternoon and found that this dataset is also off.

image

@smathermather-cm did the odm_data_copr dataset align correctly in the past?

I don’t rule out a bug at this point.


#7

Yes, AFAIK, it worked well in the past.


#8

Any update on this? I ran odm_data_copr and it is also off.


#9

Can confirm that odm_data_copr looks off.

I’ve ran another dataset (which I know has a correct gcp_file.txt) and that worked OK. Nothing stood out to me, except that odm_georef was unable to lock 3 GCPs with an error less than 1.5 meters (which seems a lot).