Support epoch-aware CRS definitions for ASP output and reference data #427
Description
Copying from #422 to preserve and continue discussing when the time comes, as this was peripheral to the main issue.
Beyond supporting unambiguous CRS definitions, at least on Earth, we also need to start specifying and tracking dataset epochs (e.g., stereo image acquisition date). And assuming we have a proper CRS definition (with epoch) for our ASP dataset, we can then rely on PROJ to correct for plate motion when the user specifies a point2dem/point2las output CRS with a fixed epoch like NAD83(2011) and the forthcoming updated NGS datums (https://geodesy.noaa.gov/datums/newdatums/index.shtml) for the US.
Most vendor camera position metadata will use the latest ITRF realization, and most users will specify a dynamic output CRS (like "WGS84", or hopefully, a specific WGS84 realization, like "WGS84 (G2139)"). This is fine, but we need to record the epoch of the observation so that these PC/DEM products can be combined with other datasets acquired at different epochs in the same dynamic CRS. For example, when combining a WV-1 DEM from 2007 with a WV-3 DEM of the same site from 2024, features on the ground will have moved >30-50 cm horizontally due to plate motion (over a pixel), depending on the location, even up to ~2 m for fastest plate motion of 10 cm/yr. See Figure 11 (https://agupubs.onlinelibrary.wiley.com/cms/asset/0224905c-ac15-4961-b2dc-b52da01bc8e6/jgrb51713-fig-0011-m.jpg) from https://agupubs.onlinelibrary.wiley.com/doi/full/10.1002/2016JB013098. This may not sound like a big deal, but the geolocation errors introduced by ignoring these issues with current ASP CRS handling/assumptions greatly exceeds accuracy of most reference lidar and GCP datasets.
