QGIS 3.10 not recognising projection information from raster created using GDAL

Question

Problem

QGIS 3.10 only partly reads projection information from raster file however QGIS 3.4 correctly reads information from same raster file.

I thought I had an issue creating the raster – I may still have but thought I should check my project was correctly set up in QGIS and discovered different behaviours between 3.4, 3.10.6 and 3.12.

Is my raster file set up correctly or have I missed something in QGIS?

Have set up QGIS by loading OSTN15 NTV2 but QGIS 3.10 fails to load the raster file as documented below. 3.4 loads same file successfully. Neither versions had the grid files installed. Information on OSTN15 installation below.

Running Raster Layer Unique Values

QGIS 3.4 – Projection: OSGB 1936 / British National Grid (EPSG:27700)

QGIS 3.10 & 3.12 – Raster Layer Unique Values - Projection: Unknown CRS: BOUNDCRS[SOURCECRS[PROJCRS["OSGB 1936 / British Na�

QGIS project steps

Create new project
Set project CRS to epsg:27700 – British National Grid
Load map layer (OS Master map section)
Load raster file
QGIS 3.4 loads immediately but in QGIS 3.10.6.0 I am faced with the window below. Note it states the source CS is unknown 3.4 recognises the source CS.
Multiple operations are possible for converting co-ordinates between these two coordinate reference systems. / Source CRS Unknown CRS
I can select cancel and my image is still drawn in the correct location and correct size. The transformation is not processed as the same error exists when I check the raster layer properties.

Raster Creation Code

src_filename = "000249.png"
dst_filename = "raster249.tif"
fileformat = "GTiff"
driver = gdal.GetDriverByName(fileformat)
dst_ds = driver.Create(dst_filename, xsize=1152, ysize=1152,
                    bands=1, eType=gdal.GDT_Byte)
raster = cv2.imread('000249.png',0)
dst_ds.SetGeoTransform([324643.6636, .017, 0, 673776.9037, 0, -.017])
srs = osr.SpatialReference()
srs.ImportFromEPSG(27700)
dest_wkt = srs.ExportToWkt()
dst_ds.SetProjection(dest_wkt)
dst_ds.GetRasterBand(1).WriteArray(raster)
dst_ds = None

Raster Format

Driver: GTiff/GeoTIFF

Size is 1152 x 1152 x 1

Projection is PROJCS["OSGB 1936 / British National Grid",GEOGCS["OSGB 1936",DATUM["OSGB_1936",SPHEROID["Airy 1830",6377563.396,299.3249646,AUTHORITY["EPSG","7001"]],TOWGS84[446.448,-125.157,542.06,0.15,0.247,0.842,-20.489],AUTHORITY["EPSG","6277"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.0174532925199433,AUTHORITY["EPSG","9122"]],AUTHORITY["EPSG","4277"]],PROJECTION["Transverse_Mercator"],PARAMETER["latitude_of_origin",49],PARAMETER["central_meridian",-2],PARAMETER["scale_factor",0.9996012717],PARAMETER["false_easting",400000],PARAMETER["false_northing",-100000],UNIT["metre",1,AUTHORITY["EPSG","9001"]],AXIS["Easting",EAST],AXIS["Northing",NORTH],AUTHORITY["EPSG","27700"]]

Origin = (324643.6636, 673776.9037)

Pixel Size = (0.017, -0.017)

Band Type=Byte

Min=0.000, Max=155.000

The raster code was initially obtained from the gdal tutorial but updated from the following stackoverflow questions.

https://gdal.org/tutorials/raster_api_tut.html

Georeferencing raster using GDAL and Python?

ogr: how to use epsg database for RD New projection?

how to set the geotransform using GDAL in python

Loading OSTN15 NTv2 in QGIS

@Ian Turton suggested checking that I have the grid files for epsg:27700 BNG installed which I had not. Here are the steps I followed.

Download zip file from Ordnance Survey
https://www.ordnancesurvey.co.uk/business-government/tools-support/os-net/for-developers

I unzipped and copied the files to C:\Program Files\QGIS 3.10\share\proj, there are other .gsb files there. Reading the posts the srs.db file that is released with QGIS should be set up correctly and only the OS files were required.
http://blog.sourcepole.ch/2014/02/18/ntv2-transformations-with-qgis/

https://www.xyht.com/gnsslocation-tech/using-ostn15-qgis

CRS project settings

It may be solved by setting the projection options. Open Setting/Options from the menu and choose CRS tab. In the "CSR for layers" group select "Use project CRS" and uncheck "Ask for datum transformation if several are available". — Zoltan, Jun 17 '20 at 06:06
@zoltan, That was a good suggestion but it did not solve my problem. 3.4 is set to prompt but it reads the raster CRS correctly. I have now set 3.10 to 'Use project CRS' but it still prompts me to select the transform. It looks like the problem is 3.10 actually reading the CRS data. — Roo, Jun 17 '20 at 06:48
You need to tell QGIS what transform you want to use and check the box to make it the default transform - But make sure you have the transform installed, the log file will tell you if it is missing — Ian Turton, Jun 17 '20 at 07:24
@Ian Turton I have pasted an image of my settings. I have new projects and layers defaulting to epsg:27700. Is that the setting you mean? As QGIS does not recognise the raster coordinate system my transform would be from 27700 to 27700 for the raster. — Roo, Jun 17 '20 at 07:55
set your CRS to epsg:27700 and then look at the project properties to see the listed transforms - again look in the log file to see if there are any errors — Ian Turton, Jun 17 '20 at 13:16
@IanTurton, thank you for getting back to me. There are no errors in the log file, only messages generated when loading QGIS. I select the first transform "Inverse of British National Grid + Transformation to WGS84 + Inverse of OSGB 1936 to WGS 84 (9) + British National Grid". Properties of the layer still set to Unknown CRS. Changed to BNG, clicked apply and the image moved down slightly. Having run this there is a transform at the bottom of the project properties, source is blank, destination has BNG, will load a different raster and check — Roo, Jun 17 '20 at 13:59
@IanTurton Loading a second raster is OK so I have a workaround for loading many files. Thank you very much. I would be good to know why I cannot load the raster in 3.10 when I can load it in 3.4. There are no datum transforms set up in 3.4. when I load 3.4 I do have the following python DeprecationWarning: invalid escape sequence. No additional errors when I load the same .tif file in 3.4. File loads and CRS for the layer correctly set for BNG after the load. — Roo, Jun 17 '20 at 14:13
see if this helps - https://www.xyht.com/gnsslocation-tech/using-ostn15-qgis/ — Ian Turton, Jun 17 '20 at 14:18
@IanTurton, Thanks. I have installed OSTN15-NTv2 (I think - I have not run a specific test yet). My displayed raster position has improved slightly which is important as I am working on a small scale. However I still get the error loading the raster file but will do more investigation around OSTN15. I will also add a short section updating the links once I have enough to share. — Roo, Jun 17 '20 at 16:13

score 2 · Accepted Answer · answered Jul 08 '20 at 20:23

2

If I'm not mistaken, it's an issue with the way QGIS (since 3.10) report CRS info taken from GDAL 3.0.4. This issue on GitHub explains everything. What you can do is use this python script written by rouault to update the metadata of your GeoTIFF (it removes the TOWGS84 string that cause the problem). The bug has been patched in GDAL 3.1.0 and when QGIS will start using this version instead of GDAL 3.0.4, your original file should be recognized correctly.

I had the same problem with other CRS (EPSG 2945 to 2952) and using the script did the trick.

answered Jul 08 '20 at 20:23

Jean-François Bourdon

167
9

Bourdon you are correct this is the problem I have. I decided to stay on QGIS 3.4 but was concerned incase I had something fundamentally wrong with my calculations. It looked like it was an incompatability between software versions as my supervisor did not see the problem. I did not dare risk any updates until my project was submitted. I am relieved to know the cause, you have made my day :-) – Roo Jul 09 '20 at 07:19

score 0 · Answer 2 · answered Jun 24 '20 at 13:30

This is not a full answer but may help someone with the same issue. I suceeded in testing my raster file on a different installation and the file loads successfully.

Problem appears to be something wrong with my installations of 3.10 and 3.12.

As I have a working version 3.4, I will not risk fixing the problem at the moment. The update to OSTN15NTv2 did not solve the issue but it was a useful suggestion as it would have given me different issues later.