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

[Mateusz Loskot]

On 30 November 2012 22:26, Pierre Racine <Pierre.Racine at sbf.ulaval.ca> wrote:
>
> 1) I'm amazed that after years of discussion and an agreement passed
> BEFORE the release of PostGIS 2.0 this problem comes to live again...
> Must be a lack of testing somewhere.

The tests were there, but they were changed to accommodate the
metadata as views.

> 2) On my side I always took for granted that the extent column in raster_columns
> (created by raster2pgsql.py)was reflecting the extent INCLUDING the padding.
> If not I would have considered this a bug.

Then, why you didn't corrected what we'd been discussing?

http://lists.osgeo.org/pipermail/postgis-devel/2009-March/005182.html

(one of examples of such discussions, including the off-list ones
which I have checked)

> It was never specified anywhere that this extent should be the one of the not padded raster.


> This is why I don't see where there is a backward compatibility problem.

"4. The right most column, and bottom row of blocks may have portions
that extend beyond the raster extent. These areas will be assumed to be
NODATA and not part of the described raster."

http://trac.osgeo.org/postgis/wiki/WKTRaster/SpecificationWorking01

> I see it more like we are doing the right way now.

I take it as a personal opinion.

> One can always achieve backward compatibility if it was relying on this bad extent
> by reviving the old raster table so his application can write whatever it wants in it.

No comments.

> 3) If a compromise is to be reached I would go for two extents proposition.

The compromise has been reached, it has been implemented.
Something has changed, because we have overlooked something.
I simply ask if it is possible to bring the the old compromises back to life.

> The actual extent constraint is the TRUE extent of what is in the DB,
> however it was produced. The new one would reflect the extent of the original
> source raster that was loaded (and might not exist anymore).
> I don't see how we will ever be able to recompute (or reapply) this
> new "with_value" extent.

Nobody asks for recomputing extent.

> (On the contrary with the actual extent
> which one can easily compute with ST_Union(ST_Extent(rast::geometry)))

ST_Extent - an aggregate function that returns the bounding box that
bounds rows of geometries.

> I think choosing to load a raster with the -t option and padding (there is a ticket #826 for
> adding the option of not padding), CHANGE and DETERMINE the nature of the stored raster
> and we do not have to keep information about the old raster.
> This is a user (or application) decision.
> (I agree that right now, because we have no option other than padding,
> we too often change this nature. This is why I would consider this ticker a higher priority.)
>
> If what is stored is a regularly tiled raster. Bravo! If not, too bad.
> An application reading a table of raster has to be able to deal with the
> fact the coverage might not be regularly tiled (and be able to compute its
> own necessary memory space based on what is in the db).
> This is unavoidable and this is what the GDAL driver do now.
>
> As I said in a previous mail this week: it is a misconception to consider a raster
> table a raster (always regularly tiled). A raster table is more like a folder
> containing a bunch of raster (a raster coverage) with all the unforeseeable the
> arrangement of these many rasters may have (unalignement, overlaps, uncompletion).

Pierre, please, don't do that, again.
Don't assume you have the monopoly for valid use cases of PostGIS Raster.
You may not like it, you may think it's a stupid idea, an unacceptable idea,
but, let me quote Tim Keitt from his PGRaster paper:

http://lists.osgeo.org/pipermail/postgis-devel/2007-July/002652.html

"Blocking storage techniques, pyramid structures and data compression
are the three key approach to improve the performance of PostGIS
PGRaster in data processing and visualization."

Blocking is a generic technique, almost equally important
as pyramids. We can't simply ignore it.

> So on my side:
>
> -1 for adding a new constraint since you can revert to the raster column
> table to support old application developed BEFORE the first official
> release (we have to remember this).

This is not about supporting an old application, but about the old
spec we've discussed.

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