Test positioning of GPS track in NAD 83 map

[pkturner]

This is not a regular PR with potential source code for production. Consider it an example map if you wish. I hope it will be adopted for testing where NAD 83 applies.

This test code should be useful in monitoring issues GH-1264 and GH-1709. It extends the template track test, with

• a map based on the NAD 83 datum

• a series of template tracks with dates corresponding to various realizations of WGS 84

The template-track-NA.xmap is like template-track.xmap, with the CRS changed to EPSG:6342 (the CRS mentioned in GH-1709), and with a suitable reference point and grivation. To create the test, the steps were:

• Specify a rectangle in EPSG:6342 projected coordinates, of the same size as the track in template-track.gpx. This will be the position where tracks are created.

side	coordinate
top	4429412.72 N
left	499280.37 E
bottom	4429393.45 N
right	499305.52 E

• Convert the track rectangle to map coordinates.

• Create 4 line objects in the map, outside of the track by 0.15 mm, similar to the lines in template-track.xmap.

• Convert the track rectangle to NAD 83 (2011) geographic coordinates. EPSG:6318 applies. The conversion is a single step of UTM transformation.

• For various dates between 1997 and 2020, convert the track rectangle from NAD 83 to WGS 84 coordinates using HTDP (see below).

• For each date's WGS 84 track rectangle, create a file template-track-NA.<year>.gpx containing that date's coordinates, with the of the track as specified in the HTDP conversion.

Because the GPS coordinates of an NAD 83-based map are a moving target, Mapper should be sensitive to the element present in GPX tracks, if it is to position the track accurately. The provided tracks all have different times and lat/lon coordinates in order to exercise this need.

Conversions

Searching online, I found that the US's National Geospatial-Intelligence Agency maintains the WGS 84 reference frame and applies it to the GPS system's operational control. The G873 ... G1762 designate realizations of WGS 84 which have succeeded one another. The number 1762 indicates the GPS calendar week when G1762 was first used.

To best convert between WGS 84 and NAD 83, I used the National Geodetic Survey's HTDP (Horizontal Time-Dependent Positioning) utility online. When converting a position using HTDP, you specify its date and a particular realization of WGS 84.

I selected various dates to exercise the different reliazations of WGS 84 which were used for GPS from 1997 to the present.

epoch	realization	EPSG
1997.0	G873	EPSG:7659
2001.0	G873	EPSG:7659
2003.0	G1150	EPSG:7661
2012.0	G1150	EPSG:7661
2013.5	G1674	EPSG:7663
2014.0	G1762	EPSG:7665
2019.73	G1762	EPSG:7665

Eventually, I compared the results of the HTDP time-dependent conversions to conversions using PROJ 7.0.1 cs2cs EPSG:6342 EPSG:7665 -f %.8fa finding that even though EPSG:7665 is not really valid before late 2013, the time-dependent Helmert transformation provided by PROJ is potentially usable. For all of the above dates, that single PROJ conversion is accurate to within 3 cm.

This PR includes a change to template_track.cpp, etc. to show how the map template-track-NA.xmap and its template tracks would appear in an ideal Mapper. That change is not intended as an answer to the GH-1264 and GH-1709 issues. When Mapper is built with all the commits on this branch (a4f1b50d), and the GDAL setting for importing GPX is disabled, the template tracks align nicely with one another and with the map objects. Thus, the test map and its template tracks are validated.

What I find notable:

• Since 1997, NAD 83 has moved about 40 cm relative to WGS 84.

• PROJ's use of the Helmert transformation defaults to the epoch which appears in its parameters. This date (1997) is arbitrary and has no significance to what Mapper is doing. If Mapper adopts EPSG:7665 or EPSG:9057 as the geographic CRS, it would be preferable to use the current date.

• The original behavior of Mapper misses the mark by 1.37 m due to omitting any datum adjustment.

• The new behavior reported in GH-1709 uses the Helmert transformation at the 1997 epoch, reducing the error to 40 cm. While the new behavior is called a "regression" in some of the GH-1709 comments, it actually reduces the error by 70%.

[pkturner]

Updated the pkturner:datum-test branch to 488f74b to share common code with the pkturner:template-consistency branch.

[pkturner]

Pushed a change which simplifies the "Improve accuracy" commit, shared with #1764.

[pkturner]

Force-pushed changes the branch for compatibility with the current master which has some new TemplateTrack tests.