QField
QField copied to clipboard
opengisch
Add way to set CRS of data from GNSS receiver
Describe the issue
There is no way to set the CRS of the data coming from GNSS, either internal or external.
The actual CRS of the data might any of a number of reference frames:
- WGS84(G2139), for non-differential solutions
- A similar frame from GLONASS, Galileo or BeiDou, for receivers that are natively in those frames, as opposed to transforming other constellations frames to WGS84
- ITRF2008, as far as I can tell, for the United States WAAS. Some other frame, or perhaps the same, for EGNOS and for each other SBAS
- For RTK, whatever CRS the reference station/network is using. That could be ITRF2014, and in the US is likely to be NAD83(2011) epoch 2010.0. It's almost certainly a national/regional datum in other areas.
It is important to note that the source's frame cannot ever be EPSG:4326 or anything else that refers to the WGS84 ensemble. That means that the input is in some frame that's an ensemble member, but we don't know which one. This is simply not true; the only member of the WGS84 ensemble that is possible (today) is WGS84(G2139). Using the ensemble codepoint will result in incorrect null transformations because the WGS84(TRANSIT) member is close to NAD83(1986), and because the intrinsic error of the ensemble is around 2m.
Reproduction steps
Search the UI for a config option and fine none.
Search the source code and see that src/core/gnssposition.h documents "WGS84".
Expected behavior
Two expectations:
- I expect the GPS config UI to allow setting a CRS.
- I expect the default to be either WGS84(G2139), ITRF2008, or ITRF2014, as a good guess to match the likely values (autonomous solutions, or SBAS). Plain WGS84 means an ensemble,which has unacceptably poor accuracy, so I expect the default not to be EPSG:4326.
Environment
QField 2.1, and from reading sources.
- WGS84(G2139), for non-differential solutions
So dynamic datum which requires epoch calculations: EPSG:9753.
Dynamic datums don't require epoch; it's just a better situation if one has an epoch-capable processing pipeline.
But that's orthogonal to the point in this ticket. Right now there is a datum tag of EPSG:4326, and that's never right (because the actual datum is always something else, not an ensemble). Yes, for autonomous and SBAS, it's something very close to ITRF2008 or ITRF2014. But for RTK or other differential, it is highly likely to be national/regional datums, which tend to be plate-fixed more or less and also quite different from ITRF2014, relative to the achievable accuracy.
If you'd liike to push on dynamic datum support -- and I'm not sure what that means in these formats right now as that's brand new in GDAL -- then please open a separate ticket about that.
Dynamic datums don't require epoch;
But that one does since it does have epoch (?). Or you mean you can just say, who cares, lets not follow the standard? You are right that it is only a tag though.
Right now there is a datum tag of EPSG:4326
Yes, since GPS always uses ECEF, so at the very least EPSG:4978, which is static and very outdated. But are you sure Android does not convert this to 3D or 2D CRS (EPSG:4326 for 2D CRS, EPSG:4979 for 3D CRS)? It is very hard to make a misatke in XYZ though, since in XYZ those are big numbers for ECEF.
Are you also sure G2139 is applied to all GPS antennas and all satellites as said in its special doc that presented G2139? Does they correct epoch every year on antennas too or are you supposed to play the prediction game on both sides? See: https://earth-info.nga.mil/php/download.php?file=(U)WGS%2084(G2139).pdf
Dynamic datums don't require epoch;
But that one does since it does have epoch (?). Or you mean you can just say, who cares, lets not follow the standard? You are right that it is only a tag though.
We are talking about QFIeld (or at least I am talking about QField, and this is the QField issue tracker). I'm honestly not sure you are discussing in the context of QField. qgis is only recently starting to get support for dealing with data with epochs. qgis uses gdal, and gdal folds epoch into the CRS as a useful approximation to full support: https://gdal.org/user/coordinate_epoch.html . qgis seems not quite there yet in handling this. postgis has an open ticket. So I believe you are talking about theoreticals, not something you are already dealing with within qgis.
Best practice for dealing with precision data in qgis, as I understand it, is to use a crust-fixed static datum, so that one does not have to carry epoch. This ticket is about making that case work.
As for standard, the EPSG codes define CRS with XYZ or LLh. They don't, as far as I am awaer, have codes with 4 coordinates per observation. I'm not aware of any support in the qgis/gdal/postgis
Right now there is a datum tag of EPSG:4326
Yes, since GPS always uses ECEF, so at the very least EPSG:4978, which is static and very outdated. But are you sure Android does not convert this to 3D or 2D CRS (EPSG:4326 for 2D CRS, EPSG:4979 for 3D CRS)? It is very hard to make a misatke in XYZ though, since in XYZ those are big numbers for ECEF.
Strictly, we are not talking about GPS -- we are talking about the NMEA position reports sent over Bluetooth SPP. Those are not in ECEF, but are in lat/lon/ortho-height/geoid-sep. They are nominally in WGS84, but in reality are in the reference frame of the reference system for differential GNSS. So 4978 which is an ensemble, is a red herring. It's also a datum ensemble, and no GPS receiver outputs coordinates in an ensemble. They output coordinates in the particular realization in use at the time, for autonomous fixes.
Are you also sure G2139 is applied to all GPS antennas and all satellites as said in its special doc that presented G2139? Does they correct epoch every year on antennas too or are you supposed to play the prediction game on both sides? See: https://earth-info.nga.mil/php/download.php?file=(U)WGS%2084(G2139).pdf
I don't know what you mean "applied to antennas". GPS has moved to G2139, and that means that the broadcast ephemeris is expressed in that frame, and thus when you compute an autonomous solution the result is in that frame. Yes, It's true that the control segment updates positions of reference stations once a year, picking coordinates that are for midyear, but that's just a very minor error source (they are on multiple plates), and I am unaware of even scholarly work that purports to detect it. Half a year's motion is small, probably 4 cm at most, and that's in the noise.
The real issue -- which I'm not sure you understand -- is that RTK in the US is in NAD83(2011) epoch 2010.0 (and similar for many other places) and those datums are not coincident with ITRFnnnn at the mm level, not even close. For me, now, it's about a meter, which is huge compared to the accuracy achievable with RTK, so the lack of labeling is a massive error source that needs working around.
So please do not drag epcoh issues into this ticket -- they don't belong. If you want to work on epoch support in qgis, gdal, postgis, QField, or something else, please don't take this as discouragement, but open a ticket about that, rather than hijacking this one.
The real issue -- which I'm not sure you understand -- is that RTK in the US is in NAD83(2011)
I understand this. I know what real time kinematics is. In fact I know about gnss-sdr and rtklib.
I don't know what you mean "applied to antennas".
From the pdf above (I think they did not update it on March 28, 2022, exactly one year after March 28, 2021):
To take maximum advantage of the new frame alignment, NGA transitioned to using The International GNSS Service (IGS) definition for the GPS satellites’ L-band transmitting antenna phase center offsets (APO) from center of mass. This transition occurred on March 28, 2021. Up to then, NGA used APO consistent with the GPS Control Segment.
The whole idea is that WE NEED to know perfectly where the center of mass is.
postgis has an open ticket.
It does not apply to proj and ArcGIS which are reference implementations, if you wish. In fact all the epoch stuff is mandatery to support ever since new Australian datum (ATRF+height+horizontal) got released.
They don't, as far as I am awaer, have codes with 4 coordinates per observation
ECEF is 3 coordinates too. And we only need ellipsoid height, as in above WGS 84 ellipsoid (EPSG:7030, not the GRS 80, a common mistake).
EGM 2008 1'x1' can be applied after and shoud be applied after. Or maybe even better the XGM 2019e.
Your points about the details of the GPS reference frame (which I won't claim are invalid) are off topic for this issue because 1) nobody actually uses those frames for anything precise, as they can only be accessed by autonomous positioning and 2) this is about being able to label data over NMEA/bluetooth as being in the frame of the RTK network or reference station.
My point about EPSG is that they do not have CRSes with a t coordinate. So you can't represent a position (3 coordinates) and epcoh of that data within the EPSG framework. And qgis uses that, at the moment. So until qgis is doing something QFIeld isn't, it's out of scope in this tracker. And even then it needs to be a separate ticket, as from a software change viewpoint it's quite different (and harder).
nobody actually uses those frames for anything precise, as they can only be accessed by autonomous positioning
Not only you are forgetting 2 and 3 band GNSS (3 band is galileo), the fact is if you have a sync'ed atomic clock you can get perfect result from JUST 3 sattelites in 3D, not 4. So as you can imagine flying planes that require at least 6 sattelities to function, were they to have atomic clock, would only need 5 or 4. The point here is that that would be 1 cm accuracy or even less (but then we go to WGS 84 inaccuracy, though ITRF2020 released in April may fix that).
Googleing keyword G2139 gives this article that has this in the abstract:
Users of WGS84 often fail to document metadata indicating the realization and epoch related to their data collections
This are the ones that should be used nowadays, GPS uses geocentric one: https://epsg.org/search/by-name/?query=G2139&sessionkey=5ssq4ahhc9
I think that is clear.
I don't know what you think is clear. When NMEA comes out of a GNSS receiver, it's very hard to know what CRS it is in.
And I don't understand your point in saying that, specifically whether you are agreeing with the issue title or objecting to it. (I think that if someone is using non-differential positioning and they believe their receiver transforms other constellation's data to WGS84(G2139) and they want to label the NMEA as being in G2139, that makes sense, as one use case among many for an ability to label.)
This would be an interesting feature for me as well, if I am getting you right. Since I am measuring in Austria (Europe) we have transformations that are ETRS89 based. Qfield works well when working in UTM projections (e.g. EPSG: 25832 - ETRS89 / UTM Zone 32 N). I suppose this is due to the fact, that it transmits the GNSS coordinates as WGS84 although they are - as it is done with RTK - in ETRS89.
However it doesn't work when I am choosing another local coordinate system (e.g. EPSG: 31254 - the one offically used in Austria). As the transformations in QGIS between those two systems are all based on ETRS89 and Qfield assumes the GNSS rover coordinates are WGS84 it can not find the proper transformation. At least thats what I am suspecting. Do you have any workarounds for this?
I would like to point out that U-blox's PointPerfect, a PPP based correction service, outputs solutions in "ITRF2014 current epoch". I wonder, would a workaround be to set the layer's CRS to WGS84, so QFIELD doesn't attempt any (incorrect) transformations, and then later in QGIS, change the CRS of the layer to match what the GNSS receiver was outputting? Based on comments in QGIS UI, it suggests that this is going to "relabel" the CRS, without reprojecting or transforming the existing features.
If your data is ITRF2014 current epoch, then that is WGS84(G1762) current epoch (I think). So you don't really need a workaround. Relabeling datum from WGS84 (an ensemble, meaning you don't know which member your datum is in) to ITRF2014 (strictly not a member, but effectively so) sounds like good strategy.
Remember that qgis (proj) will treat WGS84 and NAD83 as equal, which is wrong. I am not aware of other national frames which end up wrongly treated as equal, but if ETRS89 is an ensemble that oculd be trouble.
then that is WGS84(G1762) current epoch (I think).
No, only G2139 uses ITRF2014. G1762 uses ITRF2008.
Also G2139 is under WGS 84, so it uses WGS ellipsoid, not ITRF one. And finally the reference epoch is different between the G2139 and ITRF2014.
https://www.unoosa.org/pdf/icg/2016/icg11/wgd/02wgd.pdf
