Support epoch-aware CRS definitions for ASP output and reference data

[dshean]

Copying from https://github.com/NeoGeographyToolkit/StereoPipeline/issues/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.

[oleg-alexandrov]

Good to have this as a separate issue. Also within this scope is some tidbits of work that I ran out of time last time around:

• Option --csv-proj4 should be renamed to --csv-srs and accept a WKT (this is for reading CSV files, which may be in a different projection than what eventual produced data may be in).
• Any report file that records a datum or georeference should be standardized to WKT.
• Clean more leftover logic in the cartography module and rely more on the GDAL functions