GCP on local coordinate system

[fabiowar]

Hello,
WebODM does not seem to recognize a local reference system for GCPs.

This is the proj string I use:
+proj=merc +lat_0=45.9318804994 +lon_0=12.7230707318 +k=1 +x_0=0 +y_0=0 +ellps=WGS84 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs

This is the output log:

[INFO] Running dataset stage
[INFO] Loading dataset from: /var/www/data/da6806d5-ba1d-4173-a5f3-86038b9b9e19/images
[INFO] Loading 148 images
[INFO] Wrote images database: /var/www/data/da6806d5-ba1d-4173-a5f3-86038b9b9e19/images.json
[INFO] Found 148 usable images
[INFO] Parsing SRS header: +proj=merc +lat_0=45.9318804994 +lon_0=12.7230707318 +k=1 +x_0=0 +y_0=0 +ellps=WGS84 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs
[INFO] Generated coords file from GCP: WGS84 UTM 33N
[INFO] Parsing SRS header: WGS84 UTM 33N
[INFO] Parsing SRS header: WGS84 UTM 33N
[INFO] 39 GCP points will be used for georeferencing
[INFO] Parsing SRS header: WGS84 UTM 33N
[INFO] Finished dataset stage
[INFO] Running split stage
[INFO] Normal dataset, will process all at once.
[INFO] Finished split stage
[INFO] Running merge stage
[INFO] Normal dataset, nothing to merge.
[INFO] Finished merge stage
[INFO] Running opensfm stage
[INFO] Writing exif overrides
[INFO] Maximum photo dimensions: 4000px
[INFO] Altitude data detected, enabling it for GPS alignment

It seems to always use WGS84 UTM 33N.

At the end the processing stops with this message:

[INFO] running gdal_translate -co NUM_THREADS=12 --config GDAL_CACHEMAX 44.45% -outsize 10% 0 /var/www/data/da6806d5-ba1d-4173-a5f3-86038b9b9e19/odm_meshing/tmp/tiles.tmp.tif /var/www/data/da6806d5-ba1d-4173-a5f3-86038b9b9e19/odm_meshing/tmp/tiles.small.tif
ERROR 5: Invalid output width: 0.7
Input file size is 7, 8
Traceback (most recent call last):
File “/code/run.py”, line 68, in
app.execute()
File “/code/stages/odm_app.py”, line 95, in execute
self.first_stage.run()
File “/code/opendm/types.py”, line 356, in run
self.next_stage.run(outputs)
File “/code/opendm/types.py”, line 356, in run
self.next_stage.run(outputs)
File “/code/opendm/types.py”, line 356, in run
self.next_stage.run(outputs)
[Previous line repeated 2 more times]
File “/code/opendm/types.py”, line 337, in run
self.process(self.args, outputs)
File “/code/stages/odm_meshing.py”, line 75, in process
smooth_dsm=not args.fast_orthophoto)
File “/code/opendm/mesh.py”, line 35, in create_25dmesh
apply_smoothing=smooth_dsm
File “/code/opendm/dem/commands.py”, line 225, in create_dem
‘{geotiff_tmp} {geotiff_small}’.format(**kwargs))
File “/code/opendm/system.py”, line 79, in run
raise Exception(“Child returned {}”.format(retcode))
Exception: Child returned 1
/usr/local/lib/python3.6/dist-packages/sklearn/externals/joblib/externals/cloudpickle/cloudpickle.py:47: DeprecationWarning: the imp module is deprecated in favour of importlib; see the module’s documentation for alternative uses
import imp

Thanks for the suppot

[pierotofy]

Does it work if you set --ignore-gsd? Also make sure your --orthophoto-resolution parameters make sense for your model’s coordinates (5 cm/px might not be appropriate).

[fabiowar]

Thanks for the reply.
with this option the procedure works, but the problem of the reference system remains, let me explain:

local reference systems are often used in engineering works. These systems are defined with proj + with strings similar to these:
+proj=ortho +lat_0=45.3353906373 +lon_0=10.5355020727 +R=6378351.810 +x_0=0 +y_0=0 +units=m +no_defs

ODM does not seem to recognize these systems because, from the processing log, it transforms them into wrong global systems

---

[INFO] Parsing SRS header: +proj=ortho +lat_0=45.3353906373 +lon_0=10.5355020727 +R=6378351.810 +x_0=0 +y_0=0 +units=m +no_defs
[INFO] Generated coords file from GCP: WGS84 UTM 56N
[INFO] Parsing SRS header: WGS84 UTM 56N
[INFO] Parsing SRS header: WGS84 UTM 56N
[INFO] 394 GCP points will be used for georeferencing
[INFO] Parsing SRS header: WGS84 UTM 56N

---

the result is that the 3d model or orthophoto is positioned thousands of km from the correct point.

It would be possible to completely bypass the reference system and directly use the coordinates entered in the gcp_list.txt file (giving up the overlapping of the work on Google maps),
for example, inserting in the header of the gcp_list.txt file a string like: “no reference system or similar”

Tranks

[pierotofy]

Regardless of the CRS you specify, ODM will always pivot around the closest UTM CRS. I’m not sure why it would be off by thousands of km, but we don’t have a way to bypass this at the moment.