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

Mateusz Loskot mateusz at loskot.net
Thu Dec 6 03:26:57 PST 2012


On 3 December 2012 18:27, Pierre Racine <Pierre.Racine at sbf.ulaval.ca> wrote:
>
> 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?
>

Yes, there is potential for problems, I agree.
If you don't mind, I skip detailed discussion of these issues and jump
to your proposal below.


> 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).

That sounds like an acceptable solution.
It seems to be similar to what we've discussed with Sandro.

http://lists.osgeo.org/pipermail/postgis-devel/2012-December/023015.html

"If padding is not necessary, it would make blocksize_x|y actually
represent max_blocksize_x|y, where smaller block sizes are allowed."

what would be a fine solution.
I also mentioned there my doubt and question:

"Despite technically possible tohandle, it would complicate things though.
Is actual blocksize < max_blocksize_x|y allowed only along the right and
the bottom edge?"

Sandro's suggestion was:

http://lists.osgeo.org/pipermail/postgis-devel/2012-December/023022.html

"No, I think it should be allowed everywhere"

And that didn't sound good to me.

So, if we can agree and keep that "Right most and bottom tiles can be smaller",
for regular blocking mode actually means:

"Only tiles in the right-most column and bottom-most row of the
regularly blocked coverage can be smaller."

Can we specify it that way?

> 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.

Yes, that sounds like a consistent behaviour.

What about the constraints planned for the regular blocking mode, in the manual:

http://postgis.refractions.net/documentation/manual-svn/using_raster_dataman.html

"It is not really validated but just taken as a given so should be
used for informational.
In the future we plan to properly constrain this so that this
information is guaranteed to be right when it returns true."

That was written before the right-hand/bottom edge tiles can be
thinner/shorter change.
So, my question is: are we going to keep this plan up?

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

Thanks!

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



More information about the postgis-devel mailing list