ORTHOMOSAIC UPLOAD INCORRECT POSITION

Hi All

I have been having issues when uploading pre processed images to pix4d cloud they seem to be uploading in incorrect places (usually 20 to 30m out in most cases).

When I take these images into global mapper or civil 3d they are in the correct place but when uploading to pix4d cloud there us always a shift. Has anyone got any ideas as to why??? Below is an example of a shifted image.

Thanks in advance.

Mat

Please note the image I am uploading is not processed in pix4d but its geolocation is correct as I said within every other piece of software we bring it in to.

TLDR; To ensure that PIX4Dcloud displays the orthomosaic at the correct absolute location, the horizontal coordinate system must be defined correctly in the orthomosaics’ metadata with either a WKT string or the coordinate system’s EPSG code.


Hi Mat,

Thank you for sharing the detailed information and screenshot of the error you encountered.

My understanding is you have already identified a solution to the behavior you described on Tuesday, September 5, i.e., PIX4Dcloud displayed the orthomosaics at the incorrect absolute position. However, in case you’d like a confirmation and also to make sure someone else who encounters the same behavior has the opportunity to learn from your experience, here’s the conclusion of the investigation.

PIX4Dcloud did not display the orthomosaics you uploaded on Monday and Tuesday, September 4 and 5, specifically to projects 1620691, 1620695, and 1621649, at the correct absolute position because of how the orthomosaics’ horizontal coordinate system was defined in their metadata.

In all three instances, the orthomosaics’ metadata included a WKT string that was close to, but not perfectly identical to, the correct definition of the horizontal coordinate reference system you wanted to work with, i.e., EPSG code 27700. I anticipate you already know by now that coordinate system EPSG 27700 has several names, including, but not necessarily limited to:

  • OSGB 1936 / British National Grid
  • OSGB36 / British National Grid
  • OSGB_1936_British_National_Grid

Among the handful of horizontal CRS WKT strings in the orthomosaics’ metadata that were close to, but not perfectly identical to, the official definition of EPSG 27700, the thing to note is that they incorrectly defined the inverse flattening factor of the Airy 1830 ellipsoid, of EPSG code 7001 as 299.324975315035. According to the official definition of the ellipsoid, i.e., 7001, and the horizontal coordinate system, i.e., 27700, the correct value for the inverse flattening factor of the ellipsoid in this case is 299.3249646.

The insignificant difference between the incorrect and correct ellipsoid flattening factor in this particular case, i.e., 0.000010715035, was enough to cause the orthomosaic to shift by approximately 100 meters to the east-southeast.

Now, you’re probably wondering why PIX4Dcloud displayed the orthomosaic at the wrong absolute location while other software, including Global Mapper and Autodesk Civil 3D, displayed the same orthomosaics at the correct absolute position. The difference comes down to how each software determines the coordinate system it should use to display the orthomosaic.

With the understanding that I am not familiar with the inner workings of either Global Mapper or Autodesk Civil 3D, my understanding is both of those software by default ignore practically all of the information in the WKT string in the orthomosaics’ metadata and refer only to the EPSG code that is declared at the very end of the string, which in this case is 27700. With that EPSG code, they then use the official definition of the horizontal coordinate system according to the EPSG dataset to display the orthomosaic at the correct absolute position.

PIX4Dcloud, on the other hand, does not ignore the information in the WKT string. Instead, PIX4Dcloud uses the entire WKT string in the orthomosaics’ metadata to determine the horizontal coordinate it should use to display the orthomosaic. The benefit of this technique is that if a custom set of parameters is included in the orthomosaic’s metadata, PIX4Dcloud will take that into account instead of ignoring it and using the official definition according to the EPSG code that is mentioned at the end of the WKT string instead.

However, in this instance, since the inverse flattening factor of the orthomosaics’ horizontal coordinate system was declared with a wrong value, PIX4Dcloud used that value to display the orthomosaic, which caused the orthomosaic to be displayed at the wrong absolute position. Global Mapper and Autodesk Civil 3D, on the other hand, avoided the incorrectly declared inverse flattening factor of the ellipsoid by referring to the EPSG code at the end of the WKT string, i.e., 27700 and finding the corresponding coordinate system in their copy of the EPSG database.

Unfortunately, I don’t know why the inverse flattening factor of the EPSG 70001 was defined incorrectly in the orthomosaics’ metadata. However, as I mentioned at the beginning, my understanding is you have already identified what to do to make sure PIX4Dcloud displays your orthomosaics at the correct absolute position.

In two bullet points, to make sure your orthomosaics are displayed at the correct absolute location, you must either:

  • Ensure that all of the parameters in the WKT string in the orthomosaic’s metadata correctly define the horizontal coordinate system you want to work with. In that case, you can refer to the EPSG database, at EPSG Geodetic Parameter Dataset, for inspiration.
  • Ensure that the WKT string in the orthomosaic’s metadata refers to the EPSG code of the horizontal coordinate system you want to work with so PIX4Dcloud pulls the correct parameters from its coordinate system database. Using this particular set of orthomosaics as an example, it would simply be EPSG:27700, which is exactly what you did with the orthomosaic you uploaded on Wednesday, September 6, to project 1622622.

Knowing that you have already solved the issue yourself, we’d greatly appreciate learning what you did to ensure that the correct information was written to the orthomosaics’ metadata, i.e., EPSG:27700 in this case, instead of the incorrect set of parameters.

In the meantime, please let us know if you have any questions or comments in reaction to this information.

Thanks again for your patience.

Andrew

PS 1: I only want to make sure you know that your PIX4Dcloud license includes personal technical support by email. If you’d like to get in touch directly with a member of the team, you can contact us at https://support.pix4d.com/hc/en-us/requests/new. Of course, you’re also welcome to share your experience here with the community if you prefer.

PS 2: In this instance, thanks to the screenshot you shared, we found the projects easily enough. However, to make sure there’s a resolution as quickly as possible and to make sure it’s the correct resolution, please consider sharing either the project’s name, ID, or share link if you would like assistance with another PIX4Dcloud project. Unfortunately, sometimes there are so many viable projects to choose from that it isn’t clear precisely which project someone has in mind.