GCP datum used in processing

[Johnny5]

Hi guys, I’m trying to process a set of 3265 photos with GCPs and it failed, citing “strange values in the reconstruction”. Looking through the logs I noticed something that appears odd - although the GCP file specifies datum EPSG:8058 it seems to be changed by the processing to WGS84 UTM 43N.

[INFO] ==============
[INFO] Running dataset stage
[INFO] Loading dataset from: /var/www/data/9776812c-a881-4972-be23-6285ab5bc36b/images
[INFO] Loading 3265 images
[INFO] Wrote images database: /var/www/data/9776812c-a881-4972-be23-6285ab5bc36b/images.json
[INFO] Found 3265 usable images
[INFO] Parsing SRS header: EPSG:8058
[INFO] Parsing SRS header: WGS84 UTM 43N
[INFO] Parsing SRS header: WGS84 UTM 43N
[INFO] 114 GCP points will be used for georeferencing
[INFO] Generated coords file from GCP: WGS84 UTM 43N
[INFO] Wrote /var/www/data/9776812c-a881-4972-be23-6285ab5bc36b/odm_georeferencing/odm_georeferencing_model_geo.txt
[INFO] Parsing SRS header: WGS84 UTM 43N
[INFO] Finished dataset stage

Do the logs indicate it’s changing the datum or is this normal behaviour?

[Saijin_Naib]

Hmm, this looks like potentially a limitation of our EPSG database.

Do you have an idea of which UTM zone might be closest to where your data is from?

[Johnny5]

This location falls in UTM zone 56 (southern hemisphere)

[Saijin_Naib]

Can you convert the GCP coordinates to EPSG:32756 and try again?

[Johnny5]

I’m floundering with how to convert them…
Here’s an example of the “source” GCP data:
+proj=utm +zone=56 +south +ellps=GDA2020 +datum=GDA2020 +units=m +no_defs
GCP Label,Northing,Easting,Elevation
1,281829.271,6135667.946,36.651
2,281792.114,6135884.612,30.984
3,281671.648,6135896.629,32.722

I’ve found a couple of tools online for doing conversions but nothing that lets me specify GDA2020…but I’m not sure if that’s what I should be selecting.
Do you have any advice on how to do the conversion?

[Johnny5]

I found a conversion tool (Australian Datum Tool - BinaryEarth) so I’ll try that next

[Saijin_Naib]

If you make a pointfile layer in QGIS with EPSG:8058 as the CRS, you can convert that way.

Have you used GIS at all?

[Johnny5]

QGIS was the next application I have on my list to learn after I get comfortable with WebODM…sounds like I may need to start learning QGIS now!

[Saijin_Naib]

It is probably one of my favorite programs ever. Just amazing for data ETL among other things.

If you get it set up, I can try and walk you through how I would approach converting the CRS using QGIS.

[Johnny5]

Thanks Saijin, yes that would be greatly appreciated. I’ve got QGIS installed now so let me know your recommended steps to do the conversion (at your convenience).

[Saijin_Naib]

Can you provide the full GCP file you are going to use? I might as well give you a good copy while I work through it with you, right?

[Johnny5]

Sure, this is the GCP data in GDA2020 datum:
-------------
label,easting,northing,height (AHD)
1,281829.271,6135667.946,36.651
2,281792.114,6135884.612,30.984
3,281671.648,6135896.629,32.722
4,281579.794,6135908.706,33.462
5,281494.773,6135918.398,33.25
6,281455.674,6135928.563,32.48
7,281717.636,6135725.769,37.109
8,281755.51,6135619.74,35.985
9,281724.718,6135630.593,36.771
10,281634.587,6135631.497,35.93
11,281528.092,6135653.255,34.661
12,281545.251,6135789.791,36.122
13,281592.824,6135706.925,35.616
14,281666.081,6135762.082,37.692
15,281712.614,6135842.715,35.693
16,281740.748,6135825.219,34.481
17,281669.208,6135744.885,37.281
18,281447.391,6135889.064,34.094
19,281443.697,6135858.809,34.204
20,281442.177,6135852.753,34.236
21,281438.366,6135822.436,34.466
22,281435.211,6135816.319,34.459
23,281431.49,6135786.054,34.683
-------------

[Saijin_Naib]

1. Load into QGIS by using the Add Delimited Text function:
   

   

2. Ensure proper projection, verify location:
   

   

3. Reproject to proper CRS (EPSG:32756 should work fine):
   

   

4. Export to CSV:
   

   

5. Re-arrange columns to spec:
   

   
   
   
   

6. Import into GCP Editor Pro:
   

   

7. Start tagging images

---

CSV File:

GCP Label,Y,X,Z
1,6135667.946,281829.271,36.651
2,6135884.612,281792.114,30.984
3,6135896.629,281671.648,32.722
4,6135908.706,281579.794,33.462
5,6135918.398,281494.773,33.25
6,6135928.563,281455.674,32.48
7,6135725.769,281717.636,37.109
8,6135619.74,281755.51,35.985
9,6135630.593,281724.718,36.771
10,6135631.497,281634.587,35.93
11,6135653.255,281528.092,34.661
12,6135789.791,281545.251,36.122
13,6135706.925,281592.824,35.616
14,6135762.082,281666.081,37.692
15,6135842.715,281712.614,35.693
16,6135825.219,281740.748,34.481
17,6135744.885,281669.208,37.281
18,6135889.064,281447.391,34.094
19,6135858.809,281443.697,34.204
20,6135852.753,281442.177,34.236
21,6135822.436,281438.366,34.466
22,6135816.319,281435.211,34.459
23,6135786.054,281431.49,34.683

[Johnny5]

Thanks very much Saijin, I’ll give this a try tomorrow.

[Saijin_Naib]

Sorry for the delay

Does the location preview look sane? I don’t know what I was looking at, other than being in UTM 56S, so picking the proper projection on the input was not fun haha.

[Johnny5]

I installed the latest QGIS long term release (3.22.4) It seems to work slightly differently that the version you’re using. It displays a coverage area for each CRS & transform option, so there appear to be several valid alternatives to choose from, i.e. that cover the correct geographical area.
For some CRS it load the points after you click “Add”, and for others it prompts to select from a choice of three transforms (and then it seems to cache the transform selection).
Some CRS & transform choices put the GCPs in the right places, others are way off.
E.g.
Geometry CRS “WGS84 / UTM zone 56S” Authority ID “EPSG:32756” puts the GCPs in the right places.
“EPSG:7842 - GDA 2020” puts GCPs in the Indian ocean.
“EPSG:7844 - GDA 2020” puts them in France.
“EPSG:7856 - GDA2020 / MGA zone 56” puts them in the right places.

When I used the same selections as your example, the GCPs were placed in the Indian Ocean. The reprojection put them in the same place, no apparent change.

[Saijin_Naib]

I ran the points you gave me through Projestions (a QGIS extension) to figure out what CRS the data actually were in, since they did not appear to have come from EPSG:8058 but rather EPSG:32756. So yes, in effect, the entire workflow is superfluous prior to step 5, but the workflow will stand for other data and should be an appropriate template for you going forward.

[Johnny5]

Here’s a set of GCPs as GPS coordinates:
name,longitude,latitude,elevation
Point1,150.8531882,-33.97515668,100.4377807
Point2,150.8531008,-33.97482271,99.30138089
Point3,150.8529556,-33.97544835,101.6611261
Point4,150.8535029,-33.97558924,100.9641574
Point5,150.8533632,-33.97518796,100.3493483

I found that to import them into QGIS correctly I had to select CRS EPSG:4326 WGS 84.
I haven’t had any luck getting QGIS to convert them from longitude/lattitude to easting/northing yet.
Is that a conversion you’d expect QGIS to be able to make?

[Saijin_Naib]

Absolutely it can. Using the flow above should get you there

The only sticking point is that you’ll need to choose a CRS that has either an EPSG definition in our database, or a suitable PROJ4 definition, otherwise we can’t make sense of it at the moment.

Australia is quite advanced with their geodesy, so many of your CRSs are not representable in PROJ4, but require advancements made in later PROJ versions.

[Johnny5]

I was misreading the reproject step. Now I see it is recalculating/adjusting the GPS coordinates, but the reprojected data is still exported in longitude,latitude rather than easting,northing.
Any suggestions on how to make it perform that conversion?