[postgis-devel] [PostGIS] #2122: [raster] Real extent feature lost after metadata as views

[Pierre Racine]

> > 1) Do we need the extent to reflect the original size of the raster because:
> >
> > a) It is necessary to implement optimized reading of the raster as a regularly
> blocked raster
> >
> > or
> >
> > b) Just to remember the original size of the raster
> 
> The extent is needed to perform correct reading and optimised way too
> and to correctly process raster tiles which have been padded.
> At the moment, there is no way to determine, if padding is present
> and if it is, how much padding is present.
> 
> Remembering the original size of the raster is not needed
> as for the sake of remembering it, but if available, it would be
> considered as a mean to achieve the above (determine padding, etc.)
> 
> current size - original size = padding
> 
> if padding > 0
> ...
> else
> ...
> 
> The same could be achieved having the real (original) spatial extent
> in hand, that excludes the padding.
> It does not matter if we operate in pixel space of the world coordinates space
> here, as we can easily move between these two spaces.
> 
> The objective is to make loading and storage lossless, regardless of processing
> at loading time (arbitrary tiling, padding). ATM, it is lossy.

I always considered that when you were loading with -t XXXxYYY AND padding you were losing the original extent of the raster. You don't want to lose the original extent: you have to load with a tile size an exact divisor of the width and height OR do not pad. And that means your application optimized for regular blocking has to be able to deal with some tiles smaller than others.

Making extent the not padded extent open a kind of Pandora box:

1) How can we maintain (remove and reset) this constraint afterward?

2) What happen if some other application, edit a nodata value in the padding area? What if some tiles are added?

3) How can we know, from the metadata, what is the real extent of the coverage including the padding (this is why I would suggest , in the last resort, to have to extent: the original one and the real one)

4) Why original extent should be conserved when tiling? In the case we implement reprojection while loading (#2127), should we also keep the original SRID somewhere? If we change the pixeltype of a band while loading (#1138), should we keep the original pixeltype somewhere? What is so special about the original extent that make us wanting to keep it?

Can't the optimized regular blocking code check for the size of a tile before blindly copy data and adjust if the size is not the right one (for padded tiles)? It can still assume that each tile has its upper left corner on a regular grid (as Sandro just suggested) and that the global extent of the layer is rectangular and not rotated.

In this case we would just have to modify the "All loaded tiles have the same width and height" regularly blocked rule for " All loaded tiles have the same width and height. Right most and bottom tiles can be smaller" and applications would just have to be able to deal with that fact and the original extent could be preserved (by not padding). The -r option would not necessarily imply padding when the block sizes are not divisors of the width and height, padding would become generally unnecessary and the raster_columns extent would always be the padded one when padding is requested.

So I propose a slight change in the definition of regular_blocking that seems to fix most of the raised issue. ;-)

Pierre