-I did a survey using a Reach RS as a base, the base was set after 10 minutes in fix while conected to a internet reference station.
-I used another Reach RS as rover for surveying targets for photogrammetry. The height of the pole was correctly set in all points.
-I used and aplication supplied by the spanish goverment to conver wgs84 to etrs89 and the geoid used in spain.
-I did a drone flight photogrammetry and used the targets as reference.
-My client called me and he said that when he was making profiles he had detected a diference between my heights and the heighs of a DSM he had downloaded.
-He staked out my target with his equipment, while connected with the same reference station I had used, and he found that X and Y are ok but there is a mean diference of -3,084 meter between my survey and his survey heights (the standard desviation is 0,015). He had checked my conversion between ellipsoid and geoid and it´s ok.
-His heights match with the DSM he had.
I was using RTK with reach app and the lora radio.
The drone had PPK, the height error reporte by the photogrammetry software is about 2 meters, but I used the position reported by the base as the base position for ppk.
Ok, so RTK base/rover survey for GCP’s. PPK on the drone.
Did you manually enter the base coordinate into Reachview after you shot it using the CORS?
Can you verify that you are both using the same vertical datum? A known local elevation benchmark, or still making sure there is not an ellipsoid vs ground elevation discrepancy.
Did you re-geotag you drone photos? If so, with what software? And can you provide settings screenshots?
I keep the base coordinates that reachview came by after the 10 minutes data recopilation.
The geoid and ellipsoid diference in the area is about 50 meters, so is not the error, We also checked again the conversion from ellisoip to geoid.
I created a list of the picture positions from the ppk event file.
Good, makes sense so far. The elevation discrepancy is not ellipsoid vs geoid, but either of those in relation to “sea-level” or “ground” elevation. Ellipsoid can be converted to geoid and geoid to orthometric, but none of those are ground. Being overseas I assume you are all working off the same datum though. In the states all real elevation work is done with sea-level benchmarks and propagation of those over time.
As for the PPK, how are the base and rover antenna heights compensated for in the software?
Yes, we use the same datum from ellipsoid.
In the PPK I enter the height of the antenna as seem in the reachview app, the elevation of the antenna in the drone is more o less the height of the optical center of the lens of the camera and I can´t be so much error.
Your counterpart used a rover directly connected to the CORS and you set a base point from it then used the rover off your base. A 10 minute observation and the fact that you were getting your corrections by completely different methods might be a kink.
As for the drone with PPK “antenna” height offset, unless your setup is completely different than most than I have seen it is the phase center of the GNSS antenna to the center of the camera sensor. Is this what you meant? Not the height of the sensor from the ground.
You still haven’t referenced what software you are using for PPK. Your initial PG software error of 2m sounds like a grade rod is missing or added when it should not have been, depending on what direction the error was in.
Without experiencing it first hand I could be completely wrong on all accounts, but these are the type of causes of the issues that I most regularly see.
I do this in Germany with almost the same workflow (but PPK only). I have written a script which does all the processing for the GCPs and for the images (including lever arm correction and conversion into ETRS89/UTM and the local height system DHHN2016). It is very accurate <2.5 cm deviation compared to the official DEM.
2 m of error for your camera positions seem to be very much. Most of the camera stations should have an error below 10cm, otherwise something is wrong.
If it is not your workflow (or a missing offset) than you might have bad signal quality because of interference and vibration. Vibration is a important topic to consider if you fly in windy conditions.
Could it be that you double accounted for the offset? That you used the position of the base which was the antenna position and added the offset of the pole during PPK?
No, I´m surveing the targets with RTK. And comparing my survey with the one done with my client equipment the diference is 3,89 meters in height. This is no related to PPK.
WGS84 to ETRS80 is because reachview survey only provide wgs84.
ETRS 80 or 89? Doesn’t really matter since that is horizontal datum, just clarifying.
Ok, I thought you stated earlier that the photogrammetry software reported a 2m error, but you are talking about a 3+m error in the elevation of the actual GCP’s. When performing the PPK and combined with a bad antenna offset, this could lead to a 2m photogrammetry error which derives your surface.
As far as I have unterstood you did PPK for the image positions. If you use the base position which you retrieved during your RTK survey and add the pole this could be related to PPK?!
Correct, which is why the image values were off, but it also depends on whether the main concern in the OP was the GCPs in comparison to the pre-existing survey or the mesh generated from the drone data.
Another factor that I just thought of…
What was the state of the terrain when flown? Was there vegetation?
If so, did you create a DTM? Or did you use the DSM? Ground survey probably reference the ground if not a couple of mm below the DTM surface the drone would have shot.
Would you link the transformation tool or the parameters please? I have the impression that our reference stations operate based on ETRS89, I do not see deviations if I don’t do a conversion.
It is a common practice for the European reference network operators to configure the coordinates their ground reference stations expressed in ETRS89 datum instead of WGS84 (G1150), unfortunately very rarely is clearly stated what exact datum and realization is in being used. (from Novatel)
