Support vector reprojection

[gillins]

Closes #92.

@howff can you install and do some testing with this? There is a checkbox now in the dialog where you select the layer that says "Reproject to match". This is on by default if the layer is in a different projection to the rasters. It seems to work ok, but I haven't done a lot of testing with it, interested to know if it works with your files.

[howff]

Thanks very much for this and sorry for the delay. I wasn't entirely sure how to test code which is in a PR so I did this:

micromamba activate ~/src/tuiview/miniforge3
source miniforge3/bin/activate 
conda create -n tuiview tuiview
conda activate tuiview
pip install git+https://github.com/ubarsc/tuiview.git@refs/pull/98/head

but when I run it and try to load a raster I just get an error window NoneType object is not subscriptable (but no Python stacktrace in the console) - unrelated to vectors so presumably a mistake in how I installed it? Or may PR98 does have a bug?

[gillins]

Thanks for giving this a go and sorry for taking ages to get onto this, the whole Qt6 port took most of my time that I have to spend on Tuiview last year. I followed your instructions (which seem ok) and was able to load a raster fine. Can you confirm that tuiview from a conda env opens the file ok? You can enable the stacktrace by setting the TUIVIEW_SHOW_TRACEBACK environment variable to 1.

[howff]

This is the error I get loading a GeoTIFF

Traceback (most recent call last):
  File "miniforge3/envs/tuiview/lib/python3.13/site-packages/tuiview/viewerwindow.py", line 930, in addRasterInternal
    self.viewwidget.addRasterLayer(gdaldataset, stretch, lut)
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "miniforge3/envs/tuiview/lib/python3.13/site-packages/tuiview/viewerwidget.py", line 241, in addRasterLayer
    self.layers.addRasterLayer(gdalDataset, size.width(), size.height(),
    ~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                        stretch, lut, ignoreProjectionMismatch, quiet)
                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "miniforge3/envs/tuiview/lib/python3.13/site-packages/tuiview/viewerlayers.py", line 1673, in addRasterLayer
    layer.open(gdalDataset, width, height, stretch, lut)
    ~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "miniforge3/envs/tuiview/lib/python3.13/site-packages/tuiview/viewerlayers.py", line 451, in open
    self.lut.createLUT(self.gdalDataset, stretch, self.attributes)
    ~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "miniforge3/envs/tuiview/lib/python3.13/site-packages/tuiview/viewerLUT.py", line 932, in createLUT
    lut, self.bandinfo = self.createStretchLUT(gdalband,
                         ~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^
                stretch, lutsize, localdata)
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "miniforge3/envs/tuiview/lib/python3.13/site-packages/tuiview/viewerLUT.py", line 595, in createStretchLUT
    self.getStatisticsWithProgress(gdalband, localdata))
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^
  File "miniforge3/envs/tuiview/lib/python3.13/site-packages/tuiview/viewerLUT.py", line 745, in getStatisticsWithProgress
    if not numpy.isfinite(stats[0]):
                          ~~~~~^^^
TypeError: 'NoneType' object is not subscriptable

[gillins]

This happens with existing tuiview, right? Looks like it can't get the statistics. Any chance you could upload the file somewhere?

[howff]

Yes, tuiview straight from conda-forge is crashing. I've tried two different types of geotiff, same error, so here's 2 examples of one type of geotiff: https://drive.google.com/drive/folders/1bclp4hkbuRUE7lP0KVSrk2gX79ChOLMU?usp=sharing

[gillins]

I can't reproduce this problem with these files. What version of GDAL are you using? It is possible that something has changed recently here.

I've just created https://github.com/ubarsc/tuiview/pull/99 that checks for None being returned from the GDAL stats functions. Can you run this and let me know if this helps? Thanks

[howff]

My gdal is gdal 3.10.1 py313h49478cc_2 conda-forge. I can confirm PR #99 allows the geotiffs to load ok, thank you!

Sadly the reprojection didn't seem to work.

To try this yourself you can download some coastlines suitable for the images from here: https://data.bas.ac.uk/download/c9170b12-3865-4a73-aefe-80897161e9d9

You can reproject to latlon using:

ogr2ogr -t_srs EPSG:4326 -f "ESRI Shapefile" add_coastline_medium_res_line_v7_8_ll.shp add_coastline_medium_res_line_v7_8.shp

and you can reproject to the same projection as the images using:

ogr2ogr -t_srs '+proj=stere +lat_0=-90 +lat_ts=-71 +lon_0=-67 +X_0=0 +y_0=0 +datum=WGS84' -f "ESRI Shapefile" add_coastline_medium_res_line_v7_8_p67.shp add_coastline_medium_res_line_v7_8.shp

Only the latter is displayed, regardless of the 'Reproject' option.

[gillins]

This is what is looks like for me... You are using an environment with tuiview installed from this PR?

[gillins]

You have gcc installed and in your path?

[howff]

I ran the commands as in the comment above, i.e. inside the conda env I did this pip install git+https://github.com/ubarsc/tuiview.git@refs/pull/98/head although I have to say it didn't noticeably compile anything (this is on linux because I don't have a compiler on Windows).

[howff]

Ah, I see, reprojection does indeed work when starting from the raw overlay, and it matches the one reprojected using ogr2ogr. This is a really valuable feature, it means that the same overlay can be used on top of images in any projection, thank you.

It was the overlay where I used ogr2ogr to reproject into latlon (EPSG:4326) which didn't work. Not yet worked out why that one doesn't display.

[gillins]

@howff can you try it now? Turns out the spatial filtering never worked properly for lat/long. Which probably didn't matter when we didn't reproject. But now it matters more... Anyway, I now disable for gepgraphic projections and seems ok for me.

[howff]

That works great, thank you very much :-)