Opened 12 years ago
Closed 7 years ago
#2249 closed enhancement (fixed)
[raster] Implement ST_MakeEmptyCoverage
Reported by: | dzwarg | Owned by: | dzwarg |
---|---|---|---|
Priority: | medium | Milestone: | PostGIS 2.4.0 |
Component: | documentation | Version: | master |
Keywords: | raster | Cc: | ainomieli |
Description
Make a helper method that creates an empty coverage.
An empty coverage is a set of rasters that are regularly tiled that cover the entire pixel area of the coverage, tiling based on the tilewidth/tileheight.
Attachments (3)
Change History (18)
by , 12 years ago
Attachment: | makeemptycoverage.patch added |
---|
comment:1 by , 12 years ago
Status: | new → assigned |
---|
To handle rotation:
Create a single fake raster with as many cells as tiles in the coverage. Iterate over the x,y dimensions of that raster, and use the ULX and ULY of each fake raster pixel to generate a new empty raster with proper ULX and ULY values for the rotated component tiles in the coverage.
by , 12 years ago
Attachment: | makeemptycoverage.2.patch added |
---|
Implementation of rotatable ST_MakeEmptyCoverage()
comment:2 by , 11 years ago
Milestone: | → PostGIS 2.2.0 |
---|---|
Type: | defect → enhancement |
Version: | 2.0.x → trunk |
comment:3 by , 11 years ago
Component: | postgis → raster |
---|
follow-up: 8 comment:5 by , 10 years ago
I've taken a look at the function signature in the latest patch and got a bit scared :) I imagine a coverage creation as two steps:
- Creation of the table that would represent the coverage configuration
- Population of the coverage
The first step could be similar to AddRasterColumn, that is it only creates a structure, w/out inserting the data.
The way I'd call such a coverage-creation function would be by passing it:
Mandatory:
- The spatial extent to be covered by the coverage
- The pixel size in geographical units (the scale)
Optional:
- SRID. Unconstrained if not given. [ok, maybe this could be mandatory]
- The max size of coverage tiles in pixels. Unconstrained if not given.
I see this function instead creates a whole set of empty tiles, which is possibly a big waste of time as you probably want to later modify those tiles to have actual data in them...
Also for a big coverage it could be very easy to end up out of memory.
comment:7 by , 10 years ago
A pointer to the manual page explaining that the whole resultset from a SET-RETURNING plpgsql function is hold in memory (possibly flushed to disk temporarely) until completed: http://www.postgresql.org/docs/current/static/plpgsql-control-structures.html#PLPGSQL-STATEMENTS-RETURNING
comment:8 by , 10 years ago
Replying to strk:
I've taken a look at the function signature in the latest patch and got a bit scared :) I imagine a coverage creation as two steps:
- Creation of the table that would represent the coverage configuration
- Population of the coverage
The first step could be similar to AddRasterColumn, that is it only creates a structure, w/out inserting the data.
The way I'd call such a coverage-creation function would be by passing it:
Mandatory:
- The spatial extent to be covered by the coverage
- The pixel size in geographical units (the scale)
Optional:
- SRID. Unconstrained if not given. [ok, maybe this could be mandatory]
- The max size of coverage tiles in pixels. Unconstrained if not given.
I see this function instead creates a whole set of empty tiles, which is possibly a big waste of time as you probably want to later modify those tiles to have actual data in them...
Also for a big coverage it could be very easy to end up out of memory.
ST_MakeEmptyCoverage() should create EMPTY rasters tiles, thus having no bands and hence almost no data. It is useful for any query that want a set of reference tiles to recreate a raster coverage from an existing one or from a vector coverage (rasterizing). You use, for example, to create on the fly an empty raster table in the FROM geomtable, (SELECT ST_MakeEmptyCoverage() rast) that is used only as reference by function in the SELECT. Many functions have a reference raster as parameter from which they borrow alignment information.
comment:9 by , 10 years ago
Good point, I hadn't considered the rasters were empty ! Then I guess the only thing missing here is documentation in the manual.
comment:10 by , 10 years ago
Here is boilerplate for creating tile set with bounds (:x0, :y0, :x1, :y1) and grid dimensions (:width, :height):
SELECT cell FROM ST_MakeEmptyCoverage( 1, 1, -- tile width, tile height :width, :height, -- grid columns, grid rows :x0, :y0, -- upperleftx, upperlefty (:x1 - :x0)/(:width)::float, -- scalex (:y1 - :y0)/(:height)::float, -- scaley 0., 0., -- skewx, skewy 4326 -- srid ) cell;
- (:x0, :y0) is the upper left corner
- (:x1, :y1) is the lower right corner
- :width is the number of columns in the grid
- :height is the number of rows in the grid
comment:11 by , 9 years ago
Milestone: | PostGIS 2.2.0 → PostGIS 2.3.0 |
---|
comment:12 by , 8 years ago
Milestone: | PostGIS 2.3.0 → PostGIS 2.4.0 |
---|
I hate pushing this but I don't have time to test it out and giving the patch is so old, not sure how it plays with our current code.
comment:13 by , 7 years ago
Component: | raster → documentation |
---|
comment:14 by , 7 years ago
Cc: | added |
---|
ainomieli,
If you are still around, can you give me your name as you want to appear in credits?
Thanks, Regina
Implementation of non-rotating ST_MakeEmptyCoverage()