Is "anchor epoch" a new term, or an EPSG term? I think I know what you mean, and I'm probably off, but it seems new to me.
Formally, I feel like coordinates in a dynamic datum that do not carry an epoch are improper, but that dynamic datums specify a default epoch, so that when coordinates without a date are given, one can assume that epoch. Anchor epoch could be that. Then, transforms could be given with 7 parameters assuming a particular input datum epoch, and anther 7 as rates. Theoretically that epoch could be different from the default epoch of the frame. I bet it ~never is, because that would be even more confusing for no good reason. Is "ANCHOREPOCH" just the EPSG term for "this is the epoch assumed if you don't give a time for a set of coordinates", or is there more? Even Rouault via PROJ <[email protected]> writes: > Thinking more and looking at "ETRS89-NLD [AGRS2010] to ETRF2000 (1)", > I see it is a noop transformation, so with no time dependency... How > does that fit with the fact that ETRF2000 is dynamic. I see that > "ETRS89-NLD [AGRS2010]" uses DATUM["AGRS2010 (ETRF2000)") and has > ANCHOREPOCH[2010.5]. So I'm thinking the output coordinate when > applying "ETRS89-NLD [AGRS2010] to ETRF2000 (1)" is at coordinate > epoch 2010.5, right? Shouldn't the PROJ pipeline +proj=set > +v_4=2010.5 ? Doesn't that mean that if you give XYZ or LLh in "ETRS89-NLD [AGRS2010]" and you don't give t, then t is assumed to be 2010.5? And that if the transforms from that frame to something else are written assuming 2010.5 input, not doing anything is correct? Then there's the question of the output epoch, which should be part of the transform spec. I dimly remember an admonition that transforms among dynamic datums should have the same epoch on both sides, and coordinates should be moved from epoch to epoch in each datum to meet the transform. _______________________________________________ PROJ mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/proj
