The TL:DR: is that I believe Z($geometry) returns the Z value from the geometry in the layer, without regard to the CRS. It *should* return the Z component after transforming from layer CRS to project CRS. (qgis 3.34.10)
The longer story: I have been gathering data for generation of elevation contours, using an RTK-capable GNSS receiver and QField. I'm capturing into a table with a fid and a PointZM geometry. The elevation is corrected to base of rod from APC. I then use the Contour plugin. Generally this works well. My RTK network is in NAD83(2011) epoch 2010.0, EPSG:6319. That's my national datum and plate fixed. Due to not keeping up with a server IP address change at my RTK network provider, I booted up the system after a long time not using it, and failed to get an RTK solution. I realized this, but decided it was a good experiment to obtain a point without RTK, and assess accuracy. I captured a point as the displayed accuracy (ublox) crossed 0.600m; QField displayed 0.424m H and 1.100 m V. Unsurprisingly, the delta from record coordinates (derived from RTK, that I believe, and replicated to about 6 cm an hours later), and the point was about 1.5m horizontally, and 8.5 m vertically. I then realized that I was comparing NAD83(2011) record location coordinates with probably ITRF2008 (you tell me what frame WAAS uses, with a footnote!), or certainly something very close to some recent ITRF. To resolve the, I created a scratch layer, copied the non-RTK point into it, and relabeled the layer as ITRF2014, EPSG:7912. Labeling it WGS84 would have run into ensemble confusion and null transforms, but calling in 7912 led to a transform from ITRF2014(=ITRF2008) to NAD83(2011), and there was about 1.1 m shift, as expected. However, the Z values displayed by my label expression: coalesce(name, '_') || ' M: ' || round(M($geometry),3) || ' H: ' || round(Z($geometry),3) were the same. Even though the transform surely changed those. So, I used gdal to create a layer natively in 7912, added that, and set the same label expression. Now, the Z value is about 1.2 m lower. (This makes sense; the ellipsoids do not have the same center.) Thus I am not posting this query to gdal/proj lists; I can't argue they did anything wrong. So, it looks like Z($geometry) just pulls the value before transform, and I think it should be afterwards, just like X and Y are used to place the point on the canvas. Agreed, or am I off base? If I'm wrong about Z and the behavior is right, how do I write a label expression for the transformed Z? Thanks, Greg _______________________________________________ QGIS-User mailing list [email protected] List info: https://lists.osgeo.org/mailman/listinfo/qgis-user Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user
