Point Layer ITRF2020(PointPerfect) Transformation to Nad83(CSRS)V7(Project)

Ask the Community
1

I have a Qfield Cloud Project with the Project CRS set to EPSG(22717). I am connecting my gps receiver(U-Blox C099-F9P) to PointPerfect which transmits ITRF2020(quarterly Epoch EPSG:9989) correction data. I have set Transformations in the project settings 9989 to 22717, 22717 to 9989, 4326 to 22717 and 22717 to 4326. When I record a point with the Point Layer set to ITRF2020 the resulting project coordinate does not match NR Canada conversion.
Point Data Copied from QGIS
Lat: 43.91879931791666
Long:-80.09282190216666
h:387.6080522460936
x:572831.4388
y:4863254.0782
z:385.3951217

NRCan Transformation
Lat: 43.91879931791666
Long:-80.09282190216666
h:387.6080522460936
x:572832.234
y:4863253.035
h:388.704
Can someone tell me what transformation Qfield is using?
Should the point layer be set to WGS84(EPSG:4326)?

Imported from GitHub discussion by @DrawQuick on 2024-08-09T21:28:36Z

2

DrawQuick , can you share a sample project?

Imported from GitHub comment by @nirvn on 2024-08-10T02:44:52Z

3

Hi nirvn,
Attached is my project.
The points coloured Blue(Layer TestIRTF2020) are the ones I recorded at various times using the PointPerfect subscription service.
The points coloured Orange(Layer PointsN83V7) were recorded using my base station(RTK2GO - OvilleOne Base coordinates established using NRCan PPP).
Both sets of points were observed on the same point.
Project5540.zip

Imported from GitHub comment by @DrawQuick on 2024-08-10T14:43:57Z

4

DrawQuick , OK, here’s what is happening. While you GPS transmits coordinates in EPGS:9989, QField doesn’t yet support custom CRSes from GPS devices. At the moment, QField hardcodes all coordinates coming from GPS devices as being EPGS:4326.

In your case, what it means is that the dynamic epoch of the 9989 CRS is not considered, and the coordinates are transformed using the fixed WGS84 EPSG:4326.

You can confirm this using the python console in QGIS. When handling your lat lon height point projected in EPSG:4326 using the simple script below, we end up with the “wrong” result when transforming to EPSG:22717:

point = QgsPoint(
    -80.09282190216666,
    43.91879931791666,
    387.6080522460936
)

crsFrom = QgsCoordinateReferenceSystem('EPSG:4326')
crsTo = QgsCoordinateReferenceSystem('EPSG:22717')
transform = QgsCoordinateTransform(
    crsFrom,
    crsTo,
    QgsProject.instance().transformContext()
)

point.transform(transform, transformZ=True)
print(point.asWkt()) 

>> PointZ (572831.4387031098594889 4863254.07845740206539631 387.60805224609362085)

However, if we project your point using the EPGS:9989 CRS and set the proper epoch (say June 2024, i.e. 2024.6), we get results that essentially agree with NRCan:

point = QgsPoint(
    -80.09282190216666,
    43.91879931791666,
    387.6080522460936
)

crsFrom = QgsCoordinateReferenceSystem('EPSG:9989')
crsFrom.setCoordinateEpoch(2024.6)
crsTo = QgsCoordinateReferenceSystem('EPSG:22717')
transform = QgsCoordinateTransform(
    crsFrom,
    crsTo,
    QgsProject.instance().transformContext()
)

point.transform(transform, transformZ=True)
print(point.asWkt())

>> PointZ (572832.23591925122309476 4863253.03488864377140999 388.70384873077273369)

The solution here is for QField to gain support for customizing the CRS for external GPS devices. See this enhancement request by fellow QField users (Add way to set CRS of data from GNSS receiver · Issue #2855 · opengisch/QField · GitHub).

This is a functionality I’m really hoping to implement on day. The wait period can be greatly shorten if this gets sponsored of course. If you are interested, let us know.

Imported from GitHub comment by @nirvn on 2024-08-11T06:04:51Z