Check for georeferencing errors in GDA2020 geopdfs

For all high tech electronic equipment including GPS, PLB, chargers, phones, computers, software. Discussion of simple electrical devices such as torches, belongs in the main 'Equipment' forum.

Check for georeferencing errors in GDA2020 geopdfs

Postby Off-track » Mon 15 Apr, 2024 3:00 pm

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.
Screenshot_20240415_073627_OruxMaps.jpg
Potsville GDA2020
Screenshot_20240415_073627_OruxMaps.jpg (102.75 KiB) Viewed 2701 times
Screenshot_20240415_073707_OruxMaps.jpg
Potsville GDA94
Screenshot_20240415_073707_OruxMaps.jpg (118.99 KiB) Viewed 2701 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.
Screenshot_20240415_074107_OruxMaps.jpg
Tyalgum GDA2020
Screenshot_20240415_074107_OruxMaps.jpg (72.71 KiB) Viewed 2701 times
The attachment Screenshot_20240415_073627_OruxMaps.jpg is no longer available
Attachments
Screenshot_20240415_074016_OruxMaps.jpg
Tyalgum GDA94
Screenshot_20240415_074016_OruxMaps.jpg (96.2 KiB) Viewed 2701 times
Off-track
Nothofagus gunnii
Nothofagus gunnii
 
Posts: 48
Joined: Sat 01 Jul, 2017 8:20 pm
Region: New South Wales
Gender: Male

Re: Check for georeferencing errors in GDA2020 geopdfs

Postby tom_brennan » Wed 17 Apr, 2024 3:03 pm

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?
Bushwalking NSW - http://bushwalkingnsw.com
User avatar
tom_brennan
Athrotaxis selaginoides
Athrotaxis selaginoides
 
Posts: 1366
Joined: Wed 29 Sep, 2010 9:21 am
Location: Sydney
Region: New South Wales
Gender: Male

Re: Check for georeferencing errors in GDA2020 geopdfs

Postby Off-track » Tue 23 Apr, 2024 4:27 pm

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.
Screenshot_20240424_150359_OruxMaps.jpg
GDA2020 geopdf re-projected to WGS84
Screenshot_20240424_150359_OruxMaps.jpg (94.64 KiB) Viewed 2211 times


The cached wms maps align perfectly under my track, so the errors seem to be associated with OM handling of the geopdfs.
Screenshot_20240424_150610_OruxMaps.jpg
2016 (cached) WMS
Screenshot_20240424_150610_OruxMaps.jpg (92.58 KiB) Viewed 2211 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
Nothofagus gunnii
Nothofagus gunnii
 
Posts: 48
Joined: Sat 01 Jul, 2017 8:20 pm
Region: New South Wales
Gender: Male

Re: Check for georeferencing errors in GDA2020 geopdfs

Postby Off-track » Thu 25 Apr, 2024 10:51 am

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).
Off-track
Nothofagus gunnii
Nothofagus gunnii
 
Posts: 48
Joined: Sat 01 Jul, 2017 8:20 pm
Region: New South Wales
Gender: Male

Re: Check for georeferencing errors in GDA2020 geopdfs

Postby Off-track » Fri 03 May, 2024 3:51 pm

I eventually got a high-res geotif from spatial.nsw to load in OM. The method, starting with 9541-3N+TYALGUM.tif copied to C:\temp was:

1. Use Irfanview or gdalinfo to find that resolution of TYALGUM.tif is 11592 * 7421 pixels.
45,254 kb

2. gdalwarp -ts 11592 7421 -r average -t_srs EPSG:3857 C:\temp\9541-3N+TYALGUM.tif C:\temp\9541-3N+TYALGUM6.tif
336,077 kb (gdalwarp cannot compress; -r controls sampling which is bad in the default; must specify -ts output resolution)

3. gdal_translate -co COMPRESS=LZW C:\temp\9541-3N+TYALGUM6.tif C:\temp\9541-3N+TYALGUM7.tif
102,369 kb (not as efficient as whatever compression method spatial.nsw used, though both show LZW interleave=pixel in gdalinfo)

There was no advantage over the WMTS map (especially because contours are obscured in the current spatial.nsw geotif and geopdf).

My best interpretation is that OM cannot read GDA2020 / MGA zone 56 (EPSG:7844 / 7856) in geotif but fails to warn that is the problem.
Off-track
Nothofagus gunnii
Nothofagus gunnii
 
Posts: 48
Joined: Sat 01 Jul, 2017 8:20 pm
Region: New South Wales
Gender: Male

Re: Check for georeferencing errors in GDA2020 geopdfs

Postby Off-track » Mon 06 May, 2024 9:04 am

The interpretation that OM cannot read GDA2020 / MGA zone 56 (EPSG:7844 / 7856) in geotif is confirmed. Use on the nsw.spatial geotif files of gdalwarp with -t_srs EPSG:3857 (WGS84) or EPSG:28356 (GDA94) but not EPSG:7856 (GDA2020) results in geotif files that open without error in OM.

In gdalinfo, the GDA2020 geopdf files from nsw.spatial report EPSG:1168 / 17056 (conversion EPSG:9807 to Transverse Mercator). EPSG:1168 is the GDA2020 datum, not a coordinate system. EPSG:17056 cannot be found in epsg.io (or elsewhere) at 3 May 2024, but 17456 and 17356 were earlier MGA56 Transverse Mercator projections.

Note that gdalinfo checks only the first raster it finds (whatever that is - note the small reported size despite very high resolution of the map). The vector geopdf files have many layers with various raster images. Unfortunately,
Code: Select all
ogrinfo -al -so <source file path>
will read some of the 2016 geopdf files, but fails to read the 2023 geopdf files (unable to open). Using
Code: Select all
ogrinfo --config OGR_PDF_READ_NON_STRUCTURED YES -al <source file path>
gives some info (but no geometry). I have not found any other way to view vector geopdf metadata.

The GDA2020 geopdf files from nsw.spatial can be read by OM, but we cannot know what metadata OM is reading. Unfortunately, neither gdalwarp nor ogr2ogr can open the GDA2020 geopdfs that I tried from nsw.spatial (so I can not test it like the geotif files above). Most likely, these (multi-layer, vector) geopdf files are actually using GDA94 for the topo map frame (as reported by TerraGo). GDA94 maps do open in OM (though maps in the nsw.spatial 2016 series have slight georeferencing errors mentioned in previous posts).

So what is the practical implication? Always check georegistration of any new map on-site at the start of a walk, and have a back-up in case it is wrong. Personally I use downloaded WMTS maps in OM https://bushwalk.com/forum/viewtopic.php?f=21&t=41543, and carry a printed map https://bushwalk.com/forum/viewtopic.php?t=25619.
Off-track
Nothofagus gunnii
Nothofagus gunnii
 
Posts: 48
Joined: Sat 01 Jul, 2017 8:20 pm
Region: New South Wales
Gender: Male

Re: Check for georeferencing errors in GDA2020 geopdfs

Postby ken333 » Tue 14 May, 2024 3:08 pm

Thanks for the info. I was trying to use QGIS to combine 2 metre contours from the ELVIS NSW 2 metre grid DEMs with OSM and SIX maps. I also found the the QGIS geotiffs would not open in OM but the QGIS PDFs would. I think QGIS uses Gdal, including gdal_translate to convert files. I also changed one of the geotiff files using gdal and it worked in OM. I changed the srs to EPSG:3857. I thought it might be because I used the DEFLATE compression, not LZW, but you found LZW sometimes works. So its something else in the geotiffs OM doesnt like.
ken333
Atherosperma moschatum
Atherosperma moschatum
 
Posts: 56
Joined: Mon 07 Dec, 2015 2:17 pm
Region: Australia


Return to Techno-Babble

Who is online

Users browsing this forum: No registered users and 6 guests