Some comments/suggestions concerning plotting and other funtionality (paletted geotiffs)

[megies]

I was trying out georasters today, specifically for plotting paletted geotiff files.

Here's a few comments, in no particular order.. i might not be able to help with PRs at this point, due to time restrictions and although because I'm not fully sure georasters will work for me (main blocker for me right now is lack of reprojection and deficiencies in downsampling, esp. with paletted data).
But I wanted to at least leave these comments to help with thoughts for improvements (compare gist linked at bottom).

1. Correct map extents

Most geotiffs I work with are in some metric coordinates and pixels are aligned rectangular in X and Y. Those plots should take into account map extent, which is trivial, extracted from data.geot. It's possible to manually do it and pass it in to data.plot(..., extent=..) but it could be done automatically. See gist.

2. Track transformation changes

Methods like .resize and .extract change the map extents (compare above). Derived georaster should have it's .geot attribute updated, otherwise it's not correct anymore (e.g. adjust the dx and dy on resize and adjust x/y boundaries when doing an extract)

3. Use paletted color map defined by geotiff

Some geotiffs use paletted colormaps and these won't plot correct with just a default divergent colormap. With gdal it's easy to extract paletted colors and create a matplotlib linear segmented colormap for the array plot (see gist).

4. Resize with paletted data

Calculating new pixel values from an array of old pixels might need some other measure to compute new pixel, like a mode measure for example.

5. self.shape should be a property

When modifying data.raster (e.g. in a multiband geotif getting rid of 3rd dimension in array by reducing to one band), self.shape breaks as it is not reflecting current state of the raster anymore. I think it should just return what self.raster.shape is currently saying.

6. Multiband files problems

Multiband files, like most interestingly 3-band RGB geotiffs, are not handled correctly right now. It only needs one line of numpy to plot them correctly, moving the band-axis to the rear. Above problems with cropping/resampling the data will apply as well, though and code might need some love to take third axis into account, I bet.
Gist for the Natural Earth RGB plot: https://gist.github.com/b1d03ec98cb54656644d95a8f7abffb8

---

Summary

• plotting single band files, code should check if a color table is embedded (e.g. gdal.Open(filename).GetRasterBand(1).GetRasterColorTable()) and plot with a linear segmented custom colormap
• plotting 3-band files, it might be good to plot it as RGB by default
• extent should be set automatically on the matplotlib plot (that would also make it easier to plot into existing plots with correct map units)
• cropping/resampling operations need to update data.geot
• multi-band files (i.e. three dimensions in data array) should be handled correctly
• self.shape should be read-only property linking to self.raster.shape I think, so that it doesn't get out of sync

---

For reference, here's my scripts I was playing around with..

• paletted topographic map single-band geotiff file (file copyrighted and not available): https://gist.github.com/megies/2f4ff5949259cae98fe8d283b58bf2cb
• paletted CORINE land use single-band geotiff file (data can be downloaded here): https://gist.github.com/megies/9b7f31f617a1a4c077e83d013d27d1f9
• RGB 3-band Natural Earth imagery (link to data in gist): https://gist.github.com/megies/b1d03ec98cb54656644d95a8f7abffb8

[megies]

Can't share the input file I used in the gist, sadly, for copyright reasons..

[ozak]

Thanks for trying it out and the suggestions. I agree there is much more that could be improved. Obviously the package at this point reflects mostly my own needs, but hopefully more people can collaborate and we can improve this to make it more useful to more users.

Do you have any data that is similar and not under copyright? Or just deidentified a subset of your data?

[ozak]

I am not sure I understand your point 2. If you extract a subset fo the data, say between (x0, y0) and (x1,y1) the geot needs to be updated. Otherwise it will put the extracted raster in the wrong place (see here).

[megies]

I am not sure I understand your point 2. If you extract a subset fo the data, say between (x0, y0) and (x1,y1) the geot needs to be updated. Otherwise it will put the extracted raster in the wrong place (see here).

Exactly my point, it seems .geot is not updated by the .extract() and .resize() methods, so after using them the geot attached is just wrong for the array data.

[megies]

OK, here's a downloadable example geotiff with qualitative data and an embedded paletted colormap (and not too crazy file size):

https://www.eea.europa.eu/data-and-maps/data/global-land-cover-250m

color codes land use class

Here's the gist to plot it: https://gist.github.com/9b7f31f617a1a4c077e83d013d27d1f9

Default georasters plot (after extracting a tiny subpatch)

How it should look like

• using the embedded palette
• setting correct map extent from projection specified in file
• also correctly setting the extracted map coordinates
  

[megies]

So here's the plot for 6. Multiband RGB image

Only needs some axis juggling on the array, but cropping operations resize and extract will need some love to make them right, looks like most code is not expecting the third axis on the array (the different bands).

Link to the data file is in the gist.

https://gist.github.com/b1d03ec98cb54656644d95a8f7abffb8

[megies]

I added a short summary in first post.

[ozak]

You are right about extract, somehow I seem to have missed adding the change. But from what I see, reduce is changing the geot.

[ozak]

Multiband is not yet supported, but it's on the to-do list.

[ozak]

I will check out your examples once I have some time.

[megies]

reduce is changing the geot

didn't try reduce yet, only tried extract and resize and both didn't correct the .geot

[megies]

Multiband is not yet supported, but it's on the to-do list.

Yeah, sure, I just wanted to share my thoughts since I was looking into it anyway. No use letting all these findings go to waste by not sharing them here.

[ozak]

Sure that is perfect!

I actually meant resize not reduce. Looking at the code it is changing the geot (or at least it should have).

[megies]

I made #53 since I'm playing around in a dev environment anyway and so that you can see what I think could improve things and you can try it out as well.