<div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Thinking about how the network operates, they need to do static<br>
solutions to determine coordinates, and those could reasonably be in<br>
either ITRF2020 2015.0 or ITRF2020 day they do the observations.<br>
(Really, they should be and probably are doing static solutions<br>
repeatedly.)  With either, they could transform to 2015.0 or today's<br>
epoch.  Then, they might need to apply station velocities and load the<br>
reference station coordinates.<br></blockquote><div><br></div><div><div style="color:rgb(0,0,0)">I just posted a question with Swift Navigation Support to ask this.<br></div><div style="color:rgb(0,0,0)">I'll update this thread when/if I hear back from them.</div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">It's interesting to consider what GPS does, which as I understand it is<br>
to compute reference station coordinates once a year and use them over<br>
the year.  But the link from reference station coordiantes to<br>
clocks/orbits to user coordinates has a big enough error budget that<br>
this 1 year step of a few cm -- in varying directions for varying<br>
reference stations -- is almost certainly not detectable.<br></blockquote><div><br></div><div><div style="color:rgb(0,0,0)">GPS WGS84 reference frames that are tagged with a datum realization</div><div style="color:rgb(0,0,0)">of GPS week may be associated with an ITRF or IGS realization and its</div><div style="color:rgb(0,0,0)">attendant reference epoch and ECEF frame accuracy.</div><div style="color:rgb(0,0,0)">NOAA/NOS/NGS uses the following associations in their VDatum software:</div><div style="color:rgb(0,0,0)"><br></div><div style="color:rgb(0,0,0)">WGS84(G730): ITRF91<br>WGS84(G873): ITRF96</div><div style="color:rgb(0,0,0)">WGS84(G1150): ITRF2000</div><div style="color:rgb(0,0,0)">WGS84(G1674): ITRF2008</div><div style="color:rgb(0,0,0)">WGS84(G1762): IGS08</div><div style="color:rgb(0,0,0)">WGS84(G2139): IGS14</div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> If I want to transform from that reference system (ITRF2020) to, let's say,<br>
> ETRS89 or NAD83(2011), should I add an epoch? which one? where? what<br>
> happens if I do not set any?<br>
<br>
My somewhat hazy understanding is that ITRF2020 without a specified<br>
epoch means 2015.0.<br>
<br>
Does proj have plate motion models, to be able to answer not what a<br>
coordinates a point in space has, but a point fixed to the ground?<br></blockquote><div><br></div><div>There are subdirs for the frames which are dynamic in PROJ/data and the</div><div>plate motion model parameters are indexed at the bottom; e.g.:<br></div><div><a href="https://github.com/OSGeo/PROJ/blob/master/data/ITRF2014" target="_blank">https://github.com/OSGeo/PROJ/blob/master/data/ITRF2014</a><br></div><div><br></div><div>ITRF2020 is in EPSG and PROJ, but I don't see its definition in PROJ/data.</div><div>I'm not sure of the source for official plate motion model parameters.</div><div>Here is one reference to a model for ITRF2020:</div><div><a href="https://agupubs.onlinelibrary.wiley.com/doi/pdf/10.1029/2023GL106373" target="_blank">https://agupubs.onlinelibrary.wiley.com/doi/pdf/10.1029/2023GL106373</a><br></div><div><br></div><div>I found Even's response here re: PROJ transformations between coordinate</div><div>epochs to be useful:</div><div><a href="https://www.mail-archive.com/proj@lists.osgeo.org/msg00390.html" target="_blank">https://www.mail-archive.com/proj@lists.osgeo.org/msg00390.html</a></div><div class="gmail-yj6qo"></div><div class="gmail-adL"><br style="color:rgb(0,0,0)"></div></div></div>