Hi all,
I have a question concerning the coordinate reference system that is assigned to the WebODM output. I flew a very small mission a few days ago and made use of the new GCP editor Pro for the first time (it was also the very first time I worked with GCP + WebODM). The editor worked well - and the CRS WGS84 (EPSG:4326) was correctly assigned to the GCP file. I put this file in the folder with my pictures and uploded pictures+GCP file to WebODM. Everything seemed fine till today when I worked with the output in Qgis - I was a bit confused because WebODM assigned the CRS EPSG: 32633 to the output files (orthophoto, dsm, dtm) although the GCP file was in EPSG:4326. Additionally the GCP don´t align to the position of the targets on the orthofoto. I reprojected all the output to the same CRS - not just OTF 
Can someone tell me what possibly went wrong?
Thank you very much, kind regards
Olivia
Hey @BioGis 
WebODM will always use the closest UTM CRS to georeference a dataset. The GCP file is also internally projected to UTM during computation.
The alignment issue is a bit stranger, not sure what’s happening there; I’d recommend to share a copy of the images, the GCP file and the processed results to investigate further.
Hi @pierotofy and thank you very much for CRS clarification. That makes indeed sense 
I add a download link where you find 2 folders: first folder “all” contains the WebODM results. second folder “pictures_GCP” contans the UAV pictures plus the GCP file. There are 2 GCP that are marked by the corner of the roof and the grassy corner of the garage - not the handrail (the last two on the list), all other GCP are marked by the targets you can identify on the pictures.
https://1drv.ms/u/s!Ascxeug_dbayjp0NCbY5kUG7dGrCFA?e=48vCgu
Thank you, best regards
Olivia
A few things stand out, I’m not sure which one (or which combination) could be the root cause, but I suspect that if you fix these you’ll get much better results.
- Where do the elevation values come from? If they are from a coarse resolution DSM, I would leave them out (you can set them to “NaN” and WebODM will figure out better elevation values). Unless you’ve staked those points with an actual high accuracy GPS, don’t include elevation values.
- 9 GCPs for such a small area are probably too many, you could get by with 5-8. There’s diminishing returns by adding more GCPs (but increased chance for tagging error).
- Roof edges make poor GCPs in my experience because if you’re off by even an inch, you could be tagging the ground next to the roof edge instead of the roof edge (or worse, some images might refer to the roof edge and others to the ground next to the edge).
For example see how these 4 images don’t exactly point to the same spot (bottom left in particular).
Thank you very much for your quick answer and valuable advise. The elevation values are very precise - and thats what I need for further processing in this special case. I have to re-design this nested terraces and therefore I want to calculate the slope (other options are possible - I am aware of this fact, but wanted to try if it is possible with this approach). Also volume measurement is planned (digging) - so the outcome should be as accurate as possible 
If 9 GCP are to much I will try it again without the “natural” GCPs (roof edge and garage edge) and hope that the offset is at least smaller.
But even if I didn´t match the GCP exactly (maybe an offset of +/- 20 cm, which should not happen at all, you are right) does this result in distortions of 1.4 or even 1.6 meters in the outcome?
I will reprocess the project on monday and hope for the best 
and keep you updated on the results.
best regards
Olivia
Hi all,
here I am with the promised update on my project. I reprocessed the pictures with only 7 GCP - I got a differnd output but it´s hard to say if this is better or worse (pictures of both outputs appended - 9GCP is the firt attempt and 7 GCP the new one). The offset of the GCP is smaller now, but the whole orthophoto seems to be distorted more than before. The red polygon in the pictures is the border of the property. It shoult (more or less) allign with the fences you can see in the north (short edge) and in the south-east (longer edge). In the fist picture (9 GCP) it alligns at least better in the south… I am a little bit at a loss what goes wrong here and would be very thankful for any further advise. As stated before the GCP are measured really precise (RTK) and at least in my opinion should not be the problem.
Kind regards
Olivia
How did you plan your flight? Are the images all straight down (nadir) or otherwise?
Yes, the images are all nadir. I took some additional pictures of the terraces that were not nadir. I flew the mission “by hand” without a flight plan and stopped for every picture.
Did you include the non-nadir shots in your processing?
Yes, I included all pictures.
Here I am again with the - potential - solution /explanation of the GCPs issue. I went there again yesterday to collect GCPs and do an new flight and processing (with the bigger drone and a real flight plan 
) to maybe find out what went wrong. My epxlanation is that the spot is for an unknown reason very strange for collecting GPS data - I didn´t realise this the first time. I get an immediate FIX solution (directly after turning the device on) that stayes fixed for the whole survey ( I use just an L1 device - so thats very susbicious and never happend bevore). When cheking the collected points at home the offset was between about 5cm an 1m… So, ODM was right - and I was wrong 
Best regards
Olivia
Hey! Awesome. And thanks for following up.