Geo Registration error for new geopdf files in OM?

[Off-Track1234]

Some new geopdfs seem to give a georegistration error in OM. For example, the 2022 (NSW, Australia) geopdf Potsville 1:25K seems to be incorrectly georeferenced in OM (about 100 m N of actual location). This error is not present in the 2016 version of the same map (although it was slightly west of true location in OM). According to metadata shown by TerraGo, both versions use GDA94 (athough the new ones are distributed as GDA2020). In any case these datums are very close to WGS84.  Both map versions give the same (I assume correct) location in Adobe Reader Geospatial Location Tool.

The full reference to the map with the biggest problem in OM is: 9641-3S Pottsville 4th Edn CollarOn_2022 (at https://portal.spatial.nsw.gov.au/portal/apps/webappviewer/index.html?id=06e3c2e0de1e4efda863854048c613c6).

The screen shots are from OM 7.4.28 with a track overlay. Is there a problem with the way OM interprets metadata (Geo Registration?) in the new files?

[Off-Track1234]

I worked on this a bit more. The CollarOff versions of the maps from the NSW.spatial website are in geotiff format, and AsTiffTagViewer shows that the 2020 maps specify GDA2020 in metadata. But they will not open in OM (version 7.4.28). Nor can OM open geopdf maps converted from the 2020 Pottsville geotiff using the (very slick) online converter at https://gdal3.js.org/; though Adobe Reader opens these converted files without problem.

One workaround is to use Map tweaks > Map calibrator in OM, though it is not entirely satisfactory (probably because it uses only a single point to calibrate).

What did work well for me (after I downloaded the geotiff file from NSW.spatial to C:\temp\pottsville.tif) was to use gdal programs: first gdalwarp -t_srs EPSG:4326 C:\temp\pottsville.tif C:\temp\pottsville1.tif (to get a WGS84 re-projection - though it will still not open in OM), then gdal_translate C:\temp\pottsville1.tif C:\temp\pottsville1.pdf to get it into geopdf. This aligned perfectly under my track in OM (better than the 2016 geopdf map direct from the NSW.spatial website, which has that slight E-W error). Whew, what a run-around.
You cannot view this attachment.

The cached wms maps from NSW.spatial align perfectly under my track, so the errors seem to be associated with OM handling of the geopdfs.
You cannot view this attachment.

I think the take-home message is that OM (version 7.4.28) is happy with WGS84, but may be confused by at least some pdf maps in GDA94 or GDA2020 (these are not listed under OM Map tweaks > Map Datum, but at inception they were very close to WGS84).

[Off-Track1234]

Here is some weird stuff:
(1) OM will not open a geotif made with gdal_translate from the NSW.spatial GDA2020 geopdf (java error); but it will open the geotif after gdalwarp to WGS84 (which also warns about an ignored/misplaced neatline) - now a moderate size file, but with poor resolution.
(2) OM will open correctly a pdf made with gdal_translate from that 'warped' tif - with smaller size and better (but still degraded) resolution. Starting with the geotif from NSW.spatial then warping and translating as described in previous posts is better (though still slightly lower resolution than the NSW.spatial geopdf).
(3) OM correctly opens the original GDA2020 NSW.spatial geopdf when re-loaded (into either mapfiles or the sub-folder geopdf). Now it does not give either variable georeference errors or variable problems with zoom (experienced previously). Likewise, a re-loaded (large) pottsville1.tif now works in OM. Maybe it was some subtle corruption on copying the files? Now I am nervous - you can see the evidence in the previous screenshots.
(4) The re-loaded files do not show at first in OM, even after refresh maps, but they do show in subsequent starts (probably a little bug in OM, not a problem after the second start).