[PROJ] precise transformation from EPSG:4326 to EPSG:6706

Greg Troxel gdt at lexort.com
Mon Apr 27 12:02:47 PDT 2026


Antonio Valanzano via PROJ <proj at lists.osgeo.org> writes:

> projinfo -s EPSG:4326 -t EPSG:6706 -o proj --spatial-test intersects
>
> Does someone know if it is possible, using special options for cs2cs,  to
> achieve a transformation with an accuracy better than *1.0 m* ?

It is not, with proj, or anything else, because WGS84 is an ensemble
with an intrinsic uncertainty of 2m, because of the differences among
the members, especially the ancient and (except for confounding the
ensemble) no longer relevant WGS84(TRANSIT).

Further, there are no mechanisms (assuming you aren't part of the US
DoD) to obtain precise coordinates in any WGS84 realization -- all of
the precise/differential mechanisms use other datums.*  So I do not
think it likely that you have coordinates "in WGS84" that are accurate
to better than a meter in the first place.

I suggest that you query the source of the WGS84 coordinates and ask
them what reference frame they are in really, and how the coordinates
were determined.  Then ask them what the epoch is of each data point.
Relabel them for what they are, and start over :-)

We have a similar problem in the US, with WGS84 and transforming to
"NAD83(2011) epoch 2010.0".  Typically, I find that coordinates labeled
WGS84, if there is any basis for sub-meter accuracy, are really "the
most recent realization, with an epoch that wasn't that long ago", with
the data having been transformed to "[some unspecified] WGS84" from
something else, and that transform quite reasonably picking the most
recent realization and transforming to it.

To deal with this, I have in the past transformed from WGS84(ensemble)
to ITRF2014.  This is a null transform as ITRF2014 is ~equal to one of
the more recent WGS84 realizations (now there's ITRF2020).  Then I
transform from that to EPSG:6319, which is a real non-null transform.
In this way I can imagery to line up.  The critical point is that the
data labeled as being in hte ensemble is really in the most recent
realization (or one of the several most recent).  It's interesting to
note that in this case the imagery was ground-controlled in 6319 (NAD83
latest), exists natively in that frame, and was transformed to "[some]
WGS84" to make web mercator tiles.  Thus, the data was never captured or
ground-controlled in WGS84.

Greg

* Yes, I know Florida DOT claims WGS84 in their NTRIP server.  I am
  skeptical and would love to see a fuller articulation of what's really
  going on.
  


More information about the PROJ mailing list