Check for georeferencing errors in GDA2020 geopdfs

[Off-track]

Maybe this should be in the NSW subforum, but the warning is general. It seems necessary to check the for the correct georeferencing of new geopdf issues before trusting them. Images below are in oruxmaps (with tracks overlaid).

For example, the GDA2020 geopdf Potsville 1:25K seems to be incorrectly georeferenced (about 100 m N of actual location). This error is not present in the GDA94 version of the same map (although it was slightly west of true location). The full reference to the map with this problem is: 9641-3S Pottsville 4th Edn CollarOn_2022.

Potsville GDA2020

Screenshot_20240415_073627_OruxMaps.jpg (102.75 KiB) Viewed 680 times

Potsville GDA94

Screenshot_20240415_073707_OruxMaps.jpg (118.99 KiB) Viewed 680 times

I do not know if the error occurs in other maps. Spatial NSW will need to check (but they just say "Thank you for contacting DCS Spatial Services...We will pass this feedback on to our Experts...We consider the case resolved"). The Tyalgum map seems OK.
PS. The GDA2020 maps are generally much improved. For example, all contours are now shown in the Tyalgum map, where there were previously voids in steep areas (these voids are still in the SIX WMTS tiles). But the contours are now sometimes much harder to see - especially under similar colours such as the new Trees:dense colour (previously Closed forest in a much clearer colour), and under the widened National Park boundary lines.

Tyalgum GDA2020

Screenshot_20240415_074107_OruxMaps.jpg (72.71 KiB) Viewed 680 times

The attachment Screenshot_20240415_073627_OruxMaps.jpg is no longer available

[tom_brennan]

Are you sure it's an issue with the GeoPDF?

If I load that PDF into QGIS, it lines up nicely with various other datasets (OSM raw, OSM tiles, NSW Spatial Service tiles) for the area.

How are you getting the map into Orux? Maybe it's an issue with either Orux, or the software/process you are using to get it into Orux?

[Off-track]

I think that Oruxmaps (OM) has a problem with some of the GDA2020 files (though I can not get an answer on the OM forum, or anything sensible from the NSW spatial ‘service’).

The reason I think this is that both the 2016 and the 2020 versions of the Pottsville map give the same (only slightly inaccurate) location using the Adobe Reader Geospatial Location Tool. For some reason, metadata shown by TerraGo shows that both versions use GDA94 (although the new ones are distributed as GDA2020). Probably much like Tom in QGIS, which I have not tested.

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 map direct from the NSW.spatial website, which has that slight E-W error). Whew, what a run-around.

GDA2020 geopdf re-projected to WGS84

Screenshot_20240424_150359_OruxMaps.jpg (94.64 KiB) Viewed 190 times

The cached wms maps align perfectly under my track, so the errors seem to be associated with OM handling of the geopdfs.

2016 (cached) WMS

Screenshot_20240424_150610_OruxMaps.jpg (92.58 KiB) Viewed 190 times

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-track]

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).