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

[Javier Jimenez Shaw]

Greg.

What Florida dot offers in their ntrip server is the last realization,
WGS84(G2296).


On Mon, 27 Apr 2026, 21:02 Greg Troxel via PROJ, <proj at lists.osgeo.org>
wrote:

> 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.
>
> _______________________________________________
> PROJ mailing list
> PROJ at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/proj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20260427/019819d1/attachment.htm>