<div dir="auto">Hi Antonio<div dir="auto"><br></div><div dir="auto">EPSG:4326 is a lie. You cannot have anything accurate in that system.</div><div dir="auto">I recommend you this talk </div><div dir="auto"><a href="https://youtu.be/M2ck3cAGvhg">https://youtu.be/M2ck3cAGvhg</a></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Mon, 27 Apr 2026, 21:02 Greg Troxel via PROJ, <<a href="mailto:proj@lists.osgeo.org">proj@lists.osgeo.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Antonio Valanzano via PROJ <<a href="mailto:proj@lists.osgeo.org" target="_blank" rel="noreferrer">proj@lists.osgeo.org</a>> writes:<br>
<br>
> projinfo -s EPSG:4326 -t EPSG:6706 -o proj --spatial-test intersects<br>
><br>
> Does someone know if it is possible, using special options for cs2cs,  to<br>
> achieve a transformation with an accuracy better than *1.0 m* ?<br>
<br>
It is not, with proj, or anything else, because WGS84 is an ensemble<br>
with an intrinsic uncertainty of 2m, because of the differences among<br>
the members, especially the ancient and (except for confounding the<br>
ensemble) no longer relevant WGS84(TRANSIT).<br>
<br>
Further, there are no mechanisms (assuming you aren't part of the US<br>
DoD) to obtain precise coordinates in any WGS84 realization -- all of<br>
the precise/differential mechanisms use other datums.*  So I do not<br>
think it likely that you have coordinates "in WGS84" that are accurate<br>
to better than a meter in the first place.<br>
<br>
I suggest that you query the source of the WGS84 coordinates and ask<br>
them what reference frame they are in really, and how the coordinates<br>
were determined.  Then ask them what the epoch is of each data point.<br>
Relabel them for what they are, and start over :-)<br>
<br>
We have a similar problem in the US, with WGS84 and transforming to<br>
"NAD83(2011) epoch 2010.0".  Typically, I find that coordinates labeled<br>
WGS84, if there is any basis for sub-meter accuracy, are really "the<br>
most recent realization, with an epoch that wasn't that long ago", with<br>
the data having been transformed to "[some unspecified] WGS84" from<br>
something else, and that transform quite reasonably picking the most<br>
recent realization and transforming to it.<br>
<br>
To deal with this, I have in the past transformed from WGS84(ensemble)<br>
to ITRF2014.  This is a null transform as ITRF2014 is ~equal to one of<br>
the more recent WGS84 realizations (now there's ITRF2020).  Then I<br>
transform from that to EPSG:6319, which is a real non-null transform.<br>
In this way I can imagery to line up.  The critical point is that the<br>
data labeled as being in hte ensemble is really in the most recent<br>
realization (or one of the several most recent).  It's interesting to<br>
note that in this case the imagery was ground-controlled in 6319 (NAD83<br>
latest), exists natively in that frame, and was transformed to "[some]<br>
WGS84" to make web mercator tiles.  Thus, the data was never captured or<br>
ground-controlled in WGS84.<br>
<br>
Greg<br>
<br>
* Yes, I know Florida DOT claims WGS84 in their NTRIP server.  I am<br>
  skeptical and would love to see a fuller articulation of what's really<br>
  going on.<br>
<br>
_______________________________________________<br>
PROJ mailing list<br>
<a href="mailto:PROJ@lists.osgeo.org" target="_blank" rel="noreferrer">PROJ@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/proj" rel="noreferrer noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/proj</a><br>
</blockquote></div>