Import GCP Data from Propeller Aeropoints

PIX4Dmapper PIX4Dmapper Questions/Troubleshooting
1

I am attempting to import GCP data collected by Propeller Aeropoints and processed by the Propeller Cloud using corrections from the Propeller network.  I have not been able to successfully identify matching coordinate systems offered as output by Propeller and available as a GCP input option in PIX4D mapper.

I have attached a screen shot of the default options Propeller suggests.

 

Geographic:  NAD83(2011)  EPSC Code:  6319

Projected:  EPSG 6420

Vertical Datum:  EPSG 5703   geoid12b

Units:  Meters

 

These do not seem to match any PIX4D input options, and I cannot find PIX4D input options that match Propeller output options.

Do you have any recommendations?  I have access to the Aeropoint and plan on using them, but I cannot see how to succeed with PIX4D as the mapping solution yet.

Thank You, Mark

 

 

2

Hey Mark,

You should be able to find the projected coordinate system fairly easily within Pix4Dmapper. So long as you select feet as the unit of measurement “NAD83(2011) / California zone 3 (ftUS)” pops right up either from a text search or via the EPSG code import.

3

Okay - I think I found it.  Thank you.

4

I’m having the same problem. I tried switching to feet and still can’t see any coordinate systems for NAD83(2011). Can you explain how you solved the problem?

5

Derek,  It has been some time since and I have not been working with PIX4D / Aeropoints recently.  I do not recall from memory exactly how I solved this issue, but I did somehow.  I did end up with very good maps with the Aeropoint data.

One other issue I ran into was the elevation data from the Phantom 4 Pro V2 drone imbedded in the image files was a few hundred feet off vertically, so my Aeropoint Data could not be linked to the positioned drone shots.  I needed to somehow redefine the vertical positions for the entire map in order to allow matching to GCP points.

All of this took me a few weeks to really work though. 

I will go back though my work and see if I have any more notes to explain what I did.

6

Mark, thanks for the reply. That would be super helpful. The issue I’m having is that the Aeropoint data uses NAD83(2011) but I cannot find that coordinate system in Pix4d.

7

Hi Derek. NAD83 is a datum that is commonly used in conjunction with a projected coordinate system. You likely have to figure out what the coordinate system is and then you can find in Pix4D. The easiest way to do this is by downloading a .prj file from a site like https://epsg.io/  

Then import the PRJ in Pix4D.

8

That worked but it is still saying that there is no TOWGS which is affecting my georeferencing? Also, my points are coming in with wrong elevations. Is there a way to fix that?

9

@ Derek. The wrong elevation may be because you have the wrong vertical coordinate system declared for the GCPs or the model is just offset because it is geo-referenced using the inaccurate values of the image geotags. To fix that you would just change the image vertical CS to Height above ellipsoid and enter a number that shifts the pointcloud to get closer to where the GCP initial positions are. After changing just reoptimize to have the action take effect. Once it is close you can just mark the GCPs and it should be fine. 

10

Holden, that sounds like the issue I was dealing with and the same work around.  The image altitudes need to be at least close to the GCP altitudes to be able to link them.  I just set them all to the average AGL flight altitude.  One the camera positions are linked to the GCPs, all of the fudged altitudes are recalculated based on the relative camera positions and the know GCP altitudes.

11

I went back to some correspondence from October 2018 and found this note to a friend:

 

I solved what appears to be the last of my issues with the Aeropoint GCP data and PIX4D.

 

The GCP location data is of course very accurate, but apparently the drone GPS altitude data was off by about 60 meters.  According to PIX4D this is not uncommon.  The problem is that the GCP points appear to float about 60 meters above the point cloud for the map.  As a result PIX4D does not identify any of the images as candidates for linking to the GCPs.  

 

The workaround is to edit the altitude data in all the images to a value that is equal to the GCP height MSL plus the height of the drone (camera position) above the ground.  While this basically trashes all the image vertical data it now positions the point cloud for the surface at about the same height as the GCPs, and the GCPs can now be linked to the images easily.  The added GCP data is ultimately used for recalculating all the point cloud altitudes anyway.

 

I proposed an enhancement to PIX4D - look for candidate images for GCP linking by lateral position only and ignore altitudes.  This would have simplified my task.

 

In any case, all seems to be working.  I am now experimenting with creating separate mappings from different flights (nadir high, oblique lower) and merging the models.  For PIX4D this type of processing can only be done on the Desktop version, not on their cloud version.  The computation takes a lot so this takes lots of time and patience.

 

So far the Aeropoints were clearly the easiest step in this whole process.

 

1 Like
12

That did it! I was able to get it to work. Thank you very much for the help!