Opened 7 years ago

Closed 7 years ago

Last modified 7 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: trunk
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 Changed 7 years ago by pracine

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 Changed 7 years ago by Bborie Park

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)

comment:3 in reply to:  2 Changed 7 years ago by pracine

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 Changed 7 years ago by Bborie Park

Milestone: PostGIS FuturePostGIS 2.1.0
Status: newassigned

comment:5 Changed 7 years ago by Bborie Park

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

comment:6 Changed 7 years ago by Bborie Park

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

comment:7 Changed 7 years ago by pracine

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 Changed 7 years ago by Bborie Park

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 Changed 7 years ago by pracine

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 Changed 7 years ago by Bborie Park

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 Changed 7 years ago by Bborie Park

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 Changed 7 years ago by Bborie Park

Keywords: history added
Resolution: fixed
Status: assignedclosed

Added in r10836

comment:13 Changed 7 years ago by mloskot

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