GCP format issue?

Hi All!
I’m attempting to incorporate some GCPs into my projects. I have tried multiple times with different data sets, and it keeps failing “code 1,” but remove the GCP file and it works just fine. I’m using GCP editor pro to generate, and an Emlid system to shoot the points. The data is good, verified independently. I think it might be an issue with formatting? I’m not sure! Help!

1 Like

I re-ran the data and changed the GCP file (using the on-board GCP interface) and still got an error. I’ve tried default, 3D model, fast ortho… everything. Any ideas? I can’t get GCPs to work at all, regardless of projection, format, etc.

Here’s the end of the output from the latest test:
[INFO] running pdal translate -i “/var/www/data/b0d1f007-07f2-4ecf-9261-370faaeecba5/opensfm/undistorted/openmvs/scene_dense_dense_filtered.ply” -o “/var/www/data/b0d1f007-07f2-4ecf-9261-370faaeecba5/odm_filterpoints/point_cloud.ply” outlier range --writers.ply.sized_types=false --writers.ply.storage_mode=‘little endian’ --writers.ply.dims=“x=float,y=float,z=float,nx=float,ny=float,nz=float,red=uchar,blue=uchar,green=uchar” --filters.outlier.method=‘statistical’ --filters.outlier.mean_k=16 --filters.outlier.multiplier=2.5 --filters.range.limits=‘Classification![7:7]’
[INFO] Finished odm_filterpoints stage
[INFO] Running odm_meshing stage
[INFO] Writing ODM Mesh file in: /var/www/data/b0d1f007-07f2-4ecf-9261-370faaeecba5/odm_meshing/odm_mesh.ply
[INFO] running /code/SuperBuild/src/PoissonRecon/Bin/Linux/PoissonRecon --in /var/www/data/b0d1f007-07f2-4ecf-9261-370faaeecba5/odm_filterpoints/point_cloud.ply --out /var/www/data/b0d1f007-07f2-4ecf-9261-370faaeecba5/odm_meshing/odm_mesh.dirty.ply --depth 10 --pointWeight 4 --samplesPerNode 1.0 --threads 7 --linearFit
[WARNING] Bad average root: 1.000000
(0.499055 0.504092) (0.504092)
[WARNING] Bad average root: -0.000000
(0.504092 0.500486) (0.504092)
[WARNING] Bad average root: -0.000000
(0.504092 0.480887) (0.504092)
[INFO] running /code/build/bin/odm_cleanmesh -inputFile /var/www/data/b0d1f007-07f2-4ecf-9261-370faaeecba5/odm_meshing/odm_mesh.dirty.ply -outputFile /var/www/data/b0d1f007-07f2-4ecf-9261-370faaeecba5/odm_meshing/odm_mesh.ply -removeIslands -decimateMesh 200000
[INFO] Writing ODM 2.5D Mesh file in: /var/www/data/b0d1f007-07f2-4ecf-9261-370faaeecba5/odm_meshing/odm_25dmesh.ply
[WARNING] Maximum resolution set to GSD - 10.0% (202960.87 cm / pixel, requested resolution was 5 cm / pixel)
[INFO] ODM 2.5D DSM resolution: 457701260.38107055
[INFO] Created temporary directory: /var/www/data/b0d1f007-07f2-4ecf-9261-370faaeecba5/odm_meshing/tmp
[INFO] Creating DSM for 2.5D mesh
[INFO] running pdal info /var/www/data/b0d1f007-07f2-4ecf-9261-370faaeecba5/odm_filterpoints/point_cloud.ply > /tmp/tmpefg5a0t8.json
[INFO] Point cloud bounds are [minx: 1587121, maxx: 1587185.375] [miny: -4006695.25, maxy: -4006644.75]
[WARNING] Really low resolution DEM requested (1, 1) will set floor at 64 pixels. Resolution changed to 7151582.193454227. The scale of this reconstruction might be off.
[INFO] DEM resolution is (51, 64), max tile size is 4096, will split DEM generation into 1 tiles
[INFO] Generating /var/www/data/b0d1f007-07f2-4ecf-9261-370faaeecba5/odm_meshing/tmp/mesh_dsm_r10113864.530408897_x0_y0.tif (max, radius: 10113864.530408897, resolution: 7151582.193454227)
[INFO] running pdal pipeline -i /tmp/tmpmszkvl72.json > /dev/null 2>&1
[INFO] running gdalbuildvrt “/var/www/data/b0d1f007-07f2-4ecf-9261-370faaeecba5/odm_meshing/tmp/tiles.vrt” “/var/www/data/b0d1f007-07f2-4ecf-9261-370faaeecba5/odm_meshing/tmp/mesh_dsm_r10113864.530408897_x0_y0.tif”
0…10…20…30…40…50…60…70…80…90…100 - done.
[INFO] running gdal_translate -co NUM_THREADS=8 --config GDAL_CACHEMAX 47.55% /var/www/data/b0d1f007-07f2-4ecf-9261-370faaeecba5/odm_meshing/tmp/tiles.vrt /var/www/data/b0d1f007-07f2-4ecf-9261-370faaeecba5/odm_meshing/tmp/tiles.tmp.tif
Input file size is 1, 1
0
…10…20…30…40…50…60…70…80…90…100 - done.
[INFO] running gdal_translate -co NUM_THREADS=8 --config GDAL_CACHEMAX 47.55% -outsize 10% 0 /var/www/data/b0d1f007-07f2-4ecf-9261-370faaeecba5/odm_meshing/tmp/tiles.tmp.tif /var/www/data/b0d1f007-07f2-4ecf-9261-370faaeecba5/odm_meshing/tmp/tiles.small.tif
ERROR 5: Invalid output width: 0.1
Input file size is 1, 1
Traceback (most recent call last):
File “/code/run.py”, line 69, in
app.execute()
File “/code/stages/odm_app.py”, line 86, in execute
self.first_stage.run()
File “/code/opendm/types.py”, line 361, in run
self.next_stage.run(outputs)
File “/code/opendm/types.py”, line 361, in run
self.next_stage.run(outputs)
File “/code/opendm/types.py”, line 361, in run
self.next_stage.run(outputs)
[Previous line repeated 3 more times]
File “/code/opendm/types.py”, line 342, in run
self.process(self.args, outputs)
File “/code/stages/odm_meshing.py”, line 66, in process
mesh.create_25dmesh(tree.filtered_point_cloud, tree.odm_25dmesh,
File “/code/opendm/mesh.py”, line 25, in create_25dmesh
commands.create_dem(
File “/code/opendm/dem/commands.py”, line 221, in create_dem
run('gdal_translate ’
File “/code/opendm/system.py”, line 79, in run
raise Exception(“Child returned {}”.format(retcode))
Exception: Child returned 1

1 Like

The format looks OK. Difficult to say why it’s failing, could you share with us the images + the GCP file? You can upload them to Google Drive or Dropbox.

2 Likes

In out in the field today, but I’ll upload that data later on.

Thank you!

1 Like

Thanks for the assistance, but I figured it out. The GCPs were about 20m off vertically (I had a bad z reading for some reason on the GNSS system) and couldn’t rectify, I guess. Problem solved by fixing the GCPs to not be underground.

2 Likes

That’s a great troubleshooting thing to keep in mind!

Thanks for posting it here!

1 Like

Probably not a bad Z reading but the differences in the ellipsoidal and orthometric heights.

Usually z readings in GNSS systems are displayed as ellipsoidal heigth, so you must calculate the orthometric heigth in order to match Z in the maps.

I think you can find useful information in the web.
Orthometric height - Wikipedia

1 Like

What’s the model of the Emlid GNSS?

1 Like

Reach RS+.

See, that’s interesting, because I had calculated the orthometric height using unavco, and that was what was wrong. The GPS recorded ellipsoidal height that was approximately an accurate ortho, leading me to believe that there was a significant error in the z readings that I took. Repeating the GCPs from the same site yesterday with ntrip gave me much more accurate results.

2 Likes

Some GNSS can be loaded with the geoid data, so can display orthometric heights, some other do it in the postprocessing software. Maybe this is the case.

I have not used this Emlid GNSS systems, but I feel so curious about the Reach RS2.
How does this Emlid RS+ works for you?

1 Like

Thanks for the link! GNSS isn’t my expertise, GIS is, and so it was funny when I started exploring GPS solutions… I was like, “Wait! This is the wrong data!” I had naturally assumed that GNSS was more like a garmin, but more accurate. False. Haha.

I really like the reach units. They’re as accurate as the trimble equipment I’ve rented, much cheaper, and seem to be resilient. They gathered good data in a snowsquall a few days ago, and came out looking no worse for wear. The RS2 is my next step, because multiband will be helpful in more challenging situations. I got the rover and base at a package deal though, so two of those, plus a 2m pole and a tripod were cheaper than a single RS2.

2 Likes

Thank you for this useful information. :smiley:

3 Likes

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.