1

I get a NMEA stream exported from Applanix PosPac in the epoch the measurements took place (2019). These coordinates go into a software, that interprets the NMEA Lat Lon as EPSG:4326 with Proj4 library. From there, I export georederenced point clouds into another coordinate system, the software does the conversion from EPSG:4326 into the desired system, e.g. UTM ETRS1989 EPSG:25832, using Proj4. If I understand correctly, Proj4 must implicitly assume an epoch for the WGS84/EPSG:4326 system.

Is this epoch 1984? Or has there been an update for the WGS84 standard epoch? I can export lat lon at any epoch, so I just need to know which one is correct.

2 Answers 2

2

If you are concerned about epochs you should probably upgrade to proj6 which provides HTDP (Horizontal Time Dependent Positioning) grid shifts.

Traditionally PROJ has treated NAD83 and WGS84 as equivalent and failed to distinguish between different epochs or realizations of those datums. At the scales of much mapping this is adequate but as interest grows in high resolution imagery and other high resolution mapping this is inadequate.

3
  • To be sure, does that mean, I should export the WGS84 lat lon at epoch 1984? Does the conversion in Proj4 consider the epoch difference to the target system, for example ETRS89? Or should I "feed" Proj4 with the target epoch lat lon (e.g. 1989 when going to ETRS89). Another question is, what happens if a GPS-Sensor provides RTK corrected NMEA stream. There are GPS systems that give out RTK-corrected lat lon at the reference epoch of the base station (which could be anything, e.g. in the 90s or later). These lat lon are strictly speaking not anymore WGS84, but some mixture.
    – user155446
    Dec 20, 2019 at 9:52
  • I take that to mean that Proj 4 does not handle epochs in any meaningful way and if you need to take them into account then use Proj v6
    – Ian Turton
    Dec 20, 2019 at 9:54
  • I will forwards this proposal to the software developer, I don't have any control over this right now. But somehow, epochs must be handled by proj4, otherwise how can I transform from a system at one epoch, into a system with another epoch? From the first answer, I understand that NAD83 and WGS84 are equivalent within cm accuracy (epoch 83 vs 84), at 89 there will be a larger separation (my target system will be from 93, ETRS89 is just an example). So what is the final say, export NMEA WGS84 lat lon for transformation into ETRS89 with proj4: a) at epoch 1984, or b) target epoch (ie 1989)?
    – user155446
    Dec 20, 2019 at 10:11
0

The WGS 84 ensemble (EPSG:4326 for 2D CRS, EPSG:4979 for 3D CRS and EPSG:4978 for geocentric (ECEF) Cartesian 3D CRS and also some deprecated EPSG codes, but those do not matter) are all static, they do not have an epoch. See for yourself: https://www.icsm.gov.au/sites/default/files/ANZ%20MD%20WG%20GDA2020%20Update%202020MAR23.pptx

While the members of the WGS 84 ensembly [Transit, G730, G873, G1150, G1674 and G1762, G2139] all have an epoch, see the scheme of all the MEMBERS in Obtain CRS compliant WKT from GeoPackage with ogrinfo

When you use static ensemble you do not care about plate motion.

For example, when we do EGM 2008 1'x1' geoid it manipulates EPSG:4979 (so 3D CRS, but not ECEF).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.