OpenOrienteering
Use WGS84 (G2139) as the geographic CRS
These changes replace the geographic CRS spec string "+proj=latlong +datum=WGS84" with "EPSG:9755" for most Georeferencing purposes. EPSG:9755 is code for the current realization (G2139) of WGS84.
When creating a template with GDAL, OgrFileImport::setSRS will now recognize whether the data SRS (as detected by GDAL) is geographic and uses the ensemble/ballpark WGS84. In that case it changes the data SRS to EPSG:9755. As a result, alignment of tracks is more accurate, and tracks are aligned the same whether or not imported with GDAL.
map file format The old spec string "+proj=latlong +datum=WGS84" continues to be used when Mapper saves to file. In Mapper's file format, this string appears as the map's geographic CRS and as the CRS of some templates. Because the file format is unchanged, this version of Mapper is interoperable with v0.9.5 and earlier.
However, this compatibility has unfortunate consequences.
- Because the file has <geographic_crs_spec> elements, a Mapper that uses EPSG:9755 should put "EPSG:9755" in the file. The current PR throws away this information.
- Future users of Mapper may need to work with old maps in a way that preserves the original alignment of tracks and images. It should be possible to distinguish old maps from new.
In the future, I plan to extend this PR with a change to the file format for new maps.
fixes This is a draft, intended to address #2196 (Inaccurate import of images and tracks), along the lines suggested by @sfroyen. It fixes #1709 (Tracks positioned differently with GDAL enabled). It fixes #1264 (UTM coordinates should vary with datum).
There has been plenty of discussion of fixing these problems, along with hopes for a fix that would use PROJ to transform directly from CRS to CRS without an intermediate geographic CRS "pivot". Those efforts have not succeeded. This draft is worth considering because it is a simple change.
I added a commit which changes the WGS84 realization to the older G1762 and EPSG:9057. Evidently the version of PROJ that's in the Azure pipeline does not support EPSG:9755. The older geographic CRS provides less accurate transformation to NAD83-based georeferencing, but passes the same tests.
I have uploaded further development on the new-geographic-crs branch. This enhances the change so that when a user opens an existing map in Mapper, that map's templates are aligned just as in the past. If the user wishes to switch to use the more accurate alignment that comes from using EPSG:9057, that is optional. New maps would all use EPSG:9057.
The most useful versions are:
- 8869ce64 - basic fix using EPSG:9057 for all maps
- addecfed - preserves template alignment for old maps
- 68c70f59 - saves CRS spec "EPSG:9057" in map file
This PR is relevant to several open issues.
- #2196
- #1709
- #1264
All of these issues arise from situations when WGS84-based coordinates are converted to NAD83 coordinates, where a transformation is relevant, and leads to inaccuracy if PROJ or GDAL does not apply the transformation. Factors affecting the omission of the transformation could be
- live track vs. loaded as GPX file
- version of PROJ
- setting of whether GPX is imported using GDAL
As far as I know, the aspects of those three issues that remain are due to either
- GDAL import of data does not apply the needed transformation.
- Mapper built with PROJ 8 and later requires the fix from #2024. That fix is not present in any downloadable Mapper.
The present PR addresses GDAL import of GPX. It probably also takes care of images that have an associated geographic CRS, that are imported using GDAL.
To provide an option for the user to switch their map to the newly available accuracy of EPSG:9057, Mapper (1) provides a warning when opening an old map, and (2) asks the user to decide between the two options, when opening the Georeferencing dialog. Mapper only asks the user once. Mapper preserves that decision when the map is saved.
So that older Mappers can open the output of new Mapper, <geographic_crs_spec>+proj=latlong +datum=WGS84</geographic_crs_spec> will continue to be present in the map file. <realization_spec>EPSG:9057</realization_spec> indicates that there's more going on than just the same old ensemble +proj=latlong +datum=WGS84.
<realization_spec/> indicates that the user has chosen alignment-compatibility.
The EPSG:9057 pivot does not actually benefit non-GDAL tracks, because in Mapper v0.9.5, PROJ already finds a datum transform when converting to EPSG:6342. I tried EPSG:9755, but it failed the automated checks, presumably because the version of PROJ in the superbuild is too old.
One change to the Georeferencing code has a subtle rationale, which I express because in other respects this PR is straightforward.
Splitting off the ProjCRS from ProjTransform is needed because the ProjTransform class already had a split personality. Either you construct it with ProjTransform::crs(const QString&) or you construct it with ProjTransform(const QString&). In the first it represents a CRS, and cannot be used to transform coordinates. In the second the forward and inverse methods are available.
Implementation of this PR forces the split, because the second type of ProjTransform relies on a ProjTransform of the first type, named geographic_crs. Until now, geographic_crs has been a single object shared by all ProjTransforms. But now, different maps need different geographic_crs values, which calls for each ProjTransform of the transforming type to have its own member representing its geographic CRS.
In C++, a class (ProjTransform) can't have a regular data member of the same class.
So within ProjTransform there are distinct purposes, distinct construction, and a distinction in the data required. Splitting out the ProjCRS class is obvious. Now each ProjTransform has its own ProjCRS named geographic_crs.