Opened 11 years ago

Closed 11 years ago

Last modified 11 years ago

#2069 closed enhancement (fixed)

[raster] By default, ST_Tile() should no longer pad tiles with NODATA

Reported by: pracine Owned by: Bborie Park
Priority: high Milestone: PostGIS 2.1.0
Component: raster Version: master
Keywords: history Cc: mateusz@…

Description

So we can tile rasters which width and height do not have a common divisor without increasing the size of the coverage. Ex. width=1591 and height=1446

padwithnodata should default to FALSE

We also need a nodatavalue parameter for the case where padwithnodata is true and the rasters do not have a nodata value defined.

Change History (13)

comment:1 by pracine, 11 years ago

Summary: [raster] Add a padwithnodata and a nodatavalue parameter to ST_Clip()[raster] Add a padwithnodata and a nodatavalue parameter to ST_Tile()

comment:2 by Bborie Park, 11 years ago

Type: defectenhancement
Version: 2.0.xtrunk

So, "paddwithnodata" = FALSE would create a tile whose dimensions aren't the same as the other tiles (regularly blocked = FALSE)

in reply to:  2 comment:3 by pracine, 11 years ago

Replying to dustymugs:

So, "paddwithnodata" = FALSE would create a tile whose dimensions aren't the same as the other tiles (regularly blocked = FALSE)

Correct.

comment:4 by Bborie Park, 11 years ago

Milestone: PostGIS FuturePostGIS 2.1.0
Status: newassigned

comment:5 by Bborie Park, 11 years ago

Summary: [raster] Add a padwithnodata and a nodatavalue parameter to ST_Tile()[raster] ST_Tile() should no longer pad tiles with NODATA

comment:6 by Bborie Park, 11 years ago

This would be as part of the changes described in #2122.

comment:7 by pracine, 11 years ago

Hum. I don't really agree with the change in name as it makes the following description lose its meaning.

I would further say that the original description is actually what make things working with #2122: Padding should become optional.

comment:8 by Bborie Park, 11 years ago

From the description:

 So we can tile rasters which width and height do not have a common divisor without increasing the size of the coverage. Ex. width=1591 and height=1446

I don't see the problem with doing away with padding in the first place. Why take extra space and fill in NODATA (or min possible value) when the spec has an exemption in it? Based upon your specs…

This constraint ensures that all tile are of the same size and hence, do not overlap and do not leave gaps in the coverage. The exceptions for right-most and bottom tiles are to ensure that the coverage conserve the same extent as the original loaded raster. Reading applications have to check for the width and height of rasters (or tiles) before blindly copy their data into buffers having their sizes determined by blocksize_x and blocksize_y.

It doesn't look it it matters to be padded in the database anymore. It's the client's responsibility to handle the possibility that edge tiles can have smaller dimensions.

comment:9 by pracine, 11 years ago

Totally agree. My point is more in the direction provided in #826. But since the code is not already written for this function we can wait someone ask for it.

So you can just make it not padding for now.

comment:10 by Bborie Park, 11 years ago

Padding is useless now. If anything, the complaints typically involve, "Why is my exported raster of different size than my source raster?". Eliminating padding will get rid of that question.

comment:11 by Bborie Park, 11 years ago

Summary: [raster] ST_Tile() should no longer pad tiles with NODATA[raster] By default, ST_Tile() should no longer pad tiles with NODATA

Since I added a padding option to raster2pgsql, the parameters "padwithnodata" and "nodatavalue" can come back in.

comment:12 by Bborie Park, 11 years ago

Keywords: history added
Resolution: fixed
Status: assignedclosed

Added in r10836

comment:13 by mloskot, 11 years ago

Cc: mateusz@… added
Note: See TracTickets for help on using tickets.