[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