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

Mateusz Loskot mateusz at loskot.net
Fri Nov 30 06:51:26 PST 2012


On 30 November 2012 14:22, Sandro Santilli <strk at keybit.net> wrote:
> My 2 cents, not being such a common raster user.
> Such a change would raise many questions as of what to do with
> the padding on any kind of operation. Does the padding acts
> as nodata always ?

Yes, that is one of the assumptions.

> does has_nodata return true in presence of padding ?

Yes, it's an implied requirement imposed by the previous.
However, as originally planned and implemented in the Python loader:

"Padding bytes are generated using NODATA value or Zero if NODATA is
unavailable."

That means, padding operation may introduce NODATA if not included in
source raster.

> Is index 0 always the one within the padding or includes it ?

It is not clear what you mean exactly, do you mean column/row 0,0 ?

There are three cases:
1) no padding at all
2) partial padding
3) frame padding (padding along all four sides of raster)

In 1) index 0 is never within padding.
In 2) index 0 may or may not be within padding, depends on padding location.
In 3) index 0 is always within padding

Obviously, the case 3) is rare extreme and included for user's flexibility.

> A question:
> how does the loaded implement padding ? Does it only pad the lower-right
> tile or evenly distributes leftover pixels among all tiles ?

The raster2pgsql adds padding rightwards and downwards.
I assume, typically padding is be added in direction of increasing
column/row numbers of the raster matrix.
As the PostGIS raster is anchored at top left corner, the righwards/downwards
padding direction is 99% of cases, I guess.

> All of this seems to me as something that should be dealt with
> in upper levels, not value level.

What is the upper level?

> Why not just add support in GDAL for "trimming" the raster
> when it only contains NODATA near the margin ?

One of, because it would require actual data inspection, slow.


Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net



More information about the postgis-devel mailing list