Hello,

I am conducting mapping missions with M300 RTK with both the L2 and P1 and when I process them in Terra, the model is off around 1.5m horizontally from my GCPs.

My GCPs are collected in NAD83 (CSRS) / UTM 10N and height datum CGVD2013(CGG2013) using an emlid RS2+ connected to CAN-NET for NTRIP RTK. I have tried setting output coordinates of the model to WGS 84 / UTM zone 10N but no success. Thought it may be due to the custom base setting but that also didn't change anything.

I previously had this issue with Pix4D and figured out that it was a faulty .prj file built into the software and I had to import my own.  I have tried that within Terra and it doesn't change anything. For P1 missions it isn't the worst as I can just use the GCPs to correct the model but terra doesn't allow shifting the point cloud in the x/y so I am stuck with an inaccurate model.

Anyone have similar issues or have found a solution? I am assuming it is a projection issue within Terra because I can process the exact same P1 or L2 (photo) data in Pix4D and everything lines up perfectly.

Hi there, the system in DJI Terra is Projected Coordinate Systems. May I ask how you confirm the horizontal errors? Do you have corresponding screenshots? Please also take a look at the quality report. Please also note that LiDAR point cloud accuracy does not support the import of GCPs, only visible light missions support the import of GCPs.

I'm not sure if Terra handles CGVD.  It's always better to leave it in WGS84 and then convert later.  Unlike Pix4D or Metashape manage vertical datums very well.

DJI Mindy Posted at 2-17 01:02
Hi there, the system in DJI Terra is Projected Coordinate Systems. May I ask how you confirm the horizontal errors? Do you have corresponding screenshots? Please also take a look at the quality report. Please also note that LiDAR point cloud accuracy does not support the import of GCPs, only visible light missions support the import of GCPs.

Here is the quality report from the RGB camera of the L2. As you can see there is a large horizontal error in relation to the GCPs.

We have checked our method of obtaining GCPs against known coordinates with errors of +/- 5cm horizontally so we don't believe that our GCPs are the issue.

L2 RGB Quality Report

LV_Forestry Posted at 2-17 08:55
I'm not sure if Terra handles CGVD.  It's always better to leave it in WGS84 and then convert later.  Unlike Pix4D or Metashape manage vertical datums very well.

CGVD is built into DJI Terra so I am assuming it can handle the vertical datum but so far it doesn't seem like it. If you look at the quality report in my other reply, there is almost a 0.5m vertical error.

What software would you suggest converting the data in later?

For some reason the link to the quality report didn't work.

Here it is again.

https://drive.google.com/file/d/1xMFVfRQzmebv1dSlKM5kn8zPab0f5ws-/view?usp=sharing

capendzi Posted at 2-20 07:59
CGVD is built into DJI Terra so I am assuming it can handle the vertical datum but so far it doesn't seem like it. If you look at the quality report in my other reply, there is almost a 0.5m vertical error.

What software would you suggest converting the data in later?

The option is built in yes, but does the geoid is, and if yes does it is the right one ?

I recommend QGIS, GlobalMapper, Metashape, ArcGIs... Any software able to manage geoid.

Hello, I have noticed this issue a long time ago. In DJI Terra, you need to actually select the original NAD83 instead of NAD83(CSRS). According to my tests, NAD83 original is actually NAD83(CSRS) and NAD(CSRS) is ... well something else around 1,5m off. I hope they are gonna fix this someday, it's annoying.

SGDX Posted at 2-20 10:48
Hello, I have noticed this issue a long time ago. In DJI Terra, you need to actually select the original NAD83 instead of NAD83(CSRS). According to my tests, NAD83 original is actually NAD83(CSRS) and NAD(CSRS) is ... well something else around 1,5m off. I hope they are gonna fix this someday, it's annoying.

"According to my tests, NAD83 original is actually NAD83(CSRS)"

Do you mean that 26910 has 3157 property ?
How did you conduct your test? If you take your GCPs in a coordinate system and you make your raster in the same system, there should be no problem.

capendzi Posted at 2-20 07:52
Here is the quality report from the RGB camera of the L2. As you can see there is a large horizontal error in relation to the GCPs.

We have checked our method of obtaining GCPs against known coordinates with errors of +/- 5cm horizontally so we don't believe that our GCPs are the issue.

Hi there, could you please provide us with an open link? We're unable to access this link.

DJI Mindy Posted at 2-21 01:01
Hi there, could you please provide us with an open link? We're unable to access this link.
[view_image]

Sorry, Link should work now
https://drive.google.com/file/d/ ... s-/view?usp=sharing

LV_Forestry Posted at 2-20 13:16
"According to my tests, NAD83 original is actually NAD83(CSRS)"

Do you mean that 26910 has 3157 property ?

What I mean is when I process LiDAR, including GCP's, with an output SCR as NAD83(CSRS) (i.e. EPSG 2949), the reconstructed point cloud is always 1 to 1,5m off from my GCP's, which are surveyed in that specific CSR.

And when I process that very same dataset with GCP's with an output SCR as NAD83 Original (i.e. 32187) it's right on.

It's almost as if NAD83 is actually NAD83(CSRS) and NAD83(CSRS) is really some other CSR...

Also, in theory, these two CSR's should only be a few centimeters apart.

SGDX Posted at 2-21 10:21
What I mean is when I process LiDAR, including GCP's, with an output SCR as NAD83(CSRS) (i.e. EPSG 2949), the reconstructed point cloud is always 1 to 1,5m off from my GCP's, which are surveyed in that specific CSR.

And when I process that very same dataset with GCP's with an output SCR as NAD83 Original (i.e. 32187) it's right on.

I see.
I have no experience with MTM and Terra. But my two cents is that it would be better to stay in UTM and then perform the correction later in a more Professional software.   

Have you reported this issue to enterprise@dji.com ?

LV_Forestry Posted at 2-20 13:16
"According to my tests, NAD83 original is actually NAD83(CSRS)"

Do you mean that 26910 has 3157 property ?

This seems to work.

My GCPs collected in 3157 have the exact same location as the points in 26910 within QGIS. If I import my GCPs as 26910 into Terra and set my output as the same, the point cloud processes correctly. If I leave my GCPs as 3157, the 26910 processed data is still off by the 1.5m.

When I bring the 26910 results into QGIS, the model is still accurate to the 3157 GCPs.

It seems like most drone processing software has issues with NAD83 (CSRS)

capendzi Posted at 2-21 13:41
This seems to work.

My GCPs collected in 3157 have the exact same location as the points in 26910 within QGIS. If I import my GCPs as 26910 into Terra and set my output as the same, the point cloud processes correctly. If I leave my GCPs as 3157, the 26910 processed data is still off by the 1.5m.

NAD83 is very vast, it is made up of a multitude of systems with different transformations.

3157 : NAD83(CSRS) / UTM zone 10N
26910 :  NAD83 / UTM zone 10N

vs

2949 : NAD83(CSRS) / MTM zone 7
32187 : NAD83 / MTM zone 7

If you use MTMs in Terra and UTMs to capture GCPs, it is potentially normal that there is a gap.
The best is to stay in UTM. I don't even know in which case it is better to use MTM.

capendzi Posted at 2-21 07:52
Sorry, Link should work now
https://drive.google.com/file/d/1xMFVfRQzmebv1dSlKM5kn8zPab0f5ws-/view?usp=sharing

Thanks, we will forward it to the corresponding team for further checking.

LV_Forestry Posted at 2-22 00:56
NAD83 is very vast, it is made up of a multitude of systems with different transformations.

3157 : NAD83(CSRS) / UTM zone 10N

For my part, both my GCP's and projects are in MTM in other softwares and I never had issues. I really think there is something to look at. Thank you for the email link, I have reported it to their team!

LV_Forestry Posted at 2-22 00:56
NAD83 is very vast, it is made up of a multitude of systems with different transformations.

3157 : NAD83(CSRS) / UTM zone 10N

I am using UTM for both GCPs and Data processing. I don't use MTM.

Hello, we received a reply from the engineer saying that we need the following information for further analysis:
1. Original shooting data;
2. The camera model used for shooting;
3. Abnormal screenshots with large comparison errors and descriptions of comparison methods;
4. GCP files;
5. Output coordinate system and GCP coordinate system;
6. Quality report generated by DJI Terra

DJI Mindy Posted at 2-27 23:19
Hello, we received a reply from the engineer saying that we need the following information for further analysis:
1. Original shooting data;
2. The camera model used for shooting;

Sure, who am I sending this to? Can you provide an email address ?

SGDX Posted at 3-4 10:27
Sure, who am I sending this to? Can you provide an email address ?

You can zip the folder and put it on an online cloud (Google drive...). Then you PM the link to the moderator, recalling the subject of the post.

If the data isn't sensitive, I'm interested in receiving it too, just out of curiosity for the MTM. And then to try to find where the error comes from as well.

SGDX Posted at 3-4 10:27
Sure, who am I sending this to? Can you provide an email address ?

We've received the link you sent via PM, we will forward it to our engineer for further checking.

SGDX Posted at 3-4 10:27
Sure, who am I sending this to? Can you provide an email address ?

Hi there, we got an update from our engineer saying that because the EPSG:2949 coordinate system is a local coordinate system, it can be seen from the public PRJ file of this coordinate system that it contains seven parameters. However, currently DJI Terra cannot perfectly convert to the corresponding coordinate system through the seven parameters in the PRJ, resulting in a certain error in the horizontal Y direction. For visible light reconstruction, you can use ground control points or the seven-parameter transformation. For LiDAR reconstruction, it is recommended to use the seven-parameter transformation to output to the corresponding coordinate system.

DJI Mindy Posted at 3-11 22:46
Hi there, we got an update from our engineer saying that because the EPSG:2949 coordinate system is a local coordinate system, it can be seen from the public PRJ file of this coordinate system that it contains seven parameters. However, currently DJI Terra cannot perfectly convert to the corresponding coordinate system through the seven parameters in the PRJ, resulting in a certain error in the horizontal Y direction. For visible light reconstruction, you can use ground control points or the seven-parameter transformation. For LiDAR reconstruction, it is recommended to use the seven-parameter transformation to output to the corresponding coordinate system.

Hello,

Thank you for the investigation, I understand the issue. Is there going to be a fix for it?

SGDX Posted at 3-19 08:22
Hello,

Thank you for the investigation, I understand the issue. Is there going to be a fix for it?

We've forwarded this issue to our R&D team, and our team is working hard to analyze the issue. You can temporarily import the PRJ file for use.

DJI Mindy Posted at 3-21 01:45
We've forwarded this issue to our R&D team, and our team is working hard to analyze the issue. You can temporarily import the PRJ file for use.

Mindy,

We have the same issue as the OP. GCP's are off by 4.5ft or 6ft approx. Note, we are doing LiDAR processing and have not yet tried this on 2D.

Also, when we change our base station settings inside of Terra (prior to processing), the map shoots off into a random area on the globe (over water). This Is still a bug in 4.0.10 and was happening also in 4.0.8
I think this may have something to do it it but I could be wrong.

Is the engineering team working on a fix?

My situation:

- Emlid Reach RS3 to collect GCPs in NAD83(2011) / Louisiana South (ftUS) EPSG: 6479 + NAVD88 height (ftUS) EPSG: 6360

- Fly M300 RTK + L2 via NTRIP with good RTK Fix throughout the entire flight.

- Open Terra, Import LIDAR folder. Click the gear icon on Base Station Settings > Change to EPSG 6479. [First bug - map area shoots off into a random area (definitely not Louisiana or anywhere near where the drone's flight path)]

- Continue onward to change all settings as desired. Import GCPs in EPSG: 6479 and 6360. If I zoom ALL the way out on Map to see the globe, I can see my GCP's in the correct area.

- Process data. [Second bug: Once complete, GCP's are off by 6.2ft or so horizontally].  [Note: This happened on another map where they were off by 4.5ft or so. Oddly enough, I was able to get that particular map processed and the GCPs showed up great. Not sure what I did though.]

- Even after importing the .LAS into a separate software, the map itself was off by the same amount as Terra. Meaning, the GCPs are correct, but Terra is shifting the map somehow during processing is what we believe is happening.

ehcropydoc Posted at 3-30 18:10
My situation:

- Emlid Reach RS3 to collect GCPs in NAD83(2011) / Louisiana South (ftUS) EPSG: 6479 + NAVD88 height (ftUS) EPSG: 6360

Hi there, we will forward your issue to our engineer for further confirmation.

ehcropydoc Posted at 3-30 18:10
My situation:

- Emlid Reach RS3 to collect GCPs in NAD83(2011) / Louisiana South (ftUS) EPSG: 6479 + NAVD88 height (ftUS) EPSG: 6360

Hello, I would like to ask if you have set the X and Y coordinates to reverse direction (X is the east direction, Y is the north direction). Please set the X and Y coordinates correctly and try again.
After completing the above settings, you need to correctly set the X and Y coordinates when importing GCP. X is the east direction and Y is the north direction, and then check and test again.

DJI Mindy Posted at 4-1 03:16
Hello, I would like to ask if you have set the X and Y coordinates to reverse direction (X is the east direction, Y is the north direction). Please set the X and Y coordinates correctly and try again.
After completing the above settings, you need to correctly set the X and Y coordinates when importing GCP. X is the east direction and Y is the north direction, and then check and test again.

I am confused. Are you requesting I inverse the GCP data to upon import into Terra? This would for sure be incorrect as the GCPs would show at a different point in the world. I don't have any issue trying it but when I do swap the X/Y the GCPs dont show up on in our area.

Or are you requesting we invert the X/Y data of the base station?

Can I ask what your settings/projection is your base station settings? I have a similar issue and I am curries if it has to do with flying via an NTRIP service and terra base station settings.

ehcropydoc Posted at 4-1 04:53
I am confused. Are you requesting I inverse the GCP data to upon import into Terra? This would for sure be incorrect as the GCPs would show at a different point in the world. I don't have any issue trying it but when I do swap the X/Y the GCPs dont show up on in our area.

Or are you requesting we invert the X/Y data of the base station?

We will confirm with our team again and get back to you asap.

ehcropydoc Posted at 4-1 04:53
I am confused. Are you requesting I inverse the GCP data to upon import into Terra? This would for sure be incorrect as the GCPs would show at a different point in the world. I don't have any issue trying it but when I do swap the X/Y the GCPs dont show up on in our area.

Or are you requesting we invert the X/Y data of the base station?

Hi there, our engineers considered it may be a matter of inverting the X/Y coordinates. If you swapped the X/Y coordinates and it still does not display, please provide us with a video showing the complete operation steps, as well as the original data and GCP file for further confirmation.

ehcropydoc Posted at 3-30 18:10
My situation:

- Emlid Reach RS3 to collect GCPs in NAD83(2011) / Louisiana South (ftUS) EPSG: 6479 + NAVD88 height (ftUS) EPSG: 6360

I don't understand why you change the epsg of the base station by clicking on the gear if you have a solid RTK fix throughout the flight??

ehcropydoc Posted at 3-30 18:10
My situation:

- Emlid Reach RS3 to collect GCPs in NAD83(2011) / Louisiana South (ftUS) EPSG: 6479 + NAVD88 height (ftUS) EPSG: 6360

Ok I think I have the beginnings of a solution. The coordinates of your base station are wrong. A few centimeters horizontally probably, but certainly a few 300m in Z.

I have the impression that you did a GCP survey while being connected to a national NTRIP network, then flew the drone with a local NTRIP whose base station was installed by you and not calibrated, or with coordinates poorly transformed. Am I right?

You can send me the Rinex or OBS file of your base station to find the exact coordinates :



Forget the stories of inversion of X and Y, they didn't really understand the problem.

DJI Mindy Posted at 4-1 03:16
Hello, I would like to ask if you have set the X and Y coordinates to reverse direction (X is the east direction, Y is the north direction). Please set the X and Y coordinates correctly and try again.
After completing the above settings, you need to correctly set the X and Y coordinates when importing GCP. X is the east direction and Y is the north direction, and then check and test again.

Dear Mindy, thank you for your support, but the problem is completely different and very common with Terra.
I am not sure but I have the impression that when we import an OBS (base station) file, whether it is the Lidar RTB file or a third party OBS file, Terra performs a transformation (Simplification of coordinates )... In any case there is something wrong.

The error does not come from our national NTRIP networks because the GCPs taken with them are good.I am ok to receive a DJI representative for a field experiment to demonstrate the problem if necessary.

A quick and effective solution could be to implement a manual point cloud offset function in Terra. A window where we could select X Y and Z values to shift the entire point cloud. Or a distance and an azimuth.
*Blue Marble Geographic Global Mapper Offset feature

It would also be fantastic to be able to integrate custom TIFF rasters to offset the value of Z. Because your geoids are obviously wrong or not implemented at all.

LV_Forestry Posted at 4-3 22:52
Dear Mindy, thank you for your support, but the problem is completely different and very common with Terra.
I am not sure but I have the impression that when we import an OBS (base station) file, whether it is the Lidar RTB file or a third party OBS file, Terra performs a transformation (Simplification of coordinates )... In any case there is something wrong.

THIS:

LV_Forestry Posted at 4-3 22:52
"It would also be fantastic to be able to integrate custom TIFF rasters to offset the value of Z. Because your geoids are obviously wrong or not implemented at all."


EVERY geospatial remote sensing data processing package (LiDAR, photogrammetric, bathymetric, etc.) should have this functionality.


(FWIW, Pix4D doesn't have it either, depite ferquent hounding from the likes of me and my colleauges).

patiam Posted at 4-4 08:12
THIS:

LV_Forestry Posted at 4-3 22:52

Pat, you really need to think about switching to the Metashape team.

LV_Forestry Posted at 4-3 22:52
Dear Mindy, thank you for your support, but the problem is completely different and very common with Terra.
I am not sure but I have the impression that when we import an OBS (base station) file, whether it is the Lidar RTB file or a third party OBS file, Terra performs a transformation (Simplification of coordinates )... In any case there is something wrong.

Thanks, we will forward your feedback and suggestions to the corresponding team for evaluation.

LV_Forestry Posted at 4-4 08:24
Pat, you really need to think about switching to the Metashape team.

We do have a license or two but have found Pix to be a bit better for teaching as it has a good balance of simplicity vs. tweakability/complexity w/o being a black box. But I hear ya. At least we're not using Terra.

BTW the screenshot you posted doesn't look like it is showing the functionality in question, namely using a geoid separation raster to get to orthometric heights...