[postgis-devel] [PostGIS] #497: [raster] Start testing displaying PostGIS raster with Mapserver

[PostGIS]

#497: [raster] Start testing displaying PostGIS raster with Mapserver
----------------------------+-----------------------------------------------
 Reporter:  robe            |       Owner:  robe         
     Type:  task            |      Status:  new          
 Priority:  medium          |   Milestone:  PostGIS 2.0.0
Component:  postgis raster  |     Version:  trunk        
 Keywords:                  |  
----------------------------+-----------------------------------------------

Comment(by jorgearevalo):

 I need to construct a GDALDataset object, so, I need the raster metadata.
 The driver considers 2 working modes:[[BR]][[BR]]

 ONE_RASTER_PER_ROW: The table is a store of not necessarily related raster
 objects. You need to specify which row you want in "where" clause of
 connection string. In that case, you only need metadata for one row, of
 course.[[BR]]


 ONE_RASTER_PER_TABLE: All the table's rows are expected to form a
 coverage. Things go difficult here because you don't know if all the rows
 have the same srid, snap to the same grid and do not overlap. Anyway, in
 that case you need the metadata of your whole raster coverage. How would
 you get this?

 My rough approach was to get metadata of all raster objects. In the ideal
 case, they all share srid, size, pixel size and skew. You can calculate
 the extent of the raster. That works for the ideal case, but this is slow,
 and doesn't take into account other raster arrangements. If not all the
 rows share grid alignment, I should resample all the rows to the grid of
 the first one, or provide a new grid alingment for all the rows.

 Then, constructing a GDALDataset can be a very slow task, as you have
 experienced. How would be the better way to get the metadata for a whole
 raster coverage when you only have the metadata of each separated block
 and you don't know if all the blocks snap to the same grid or not?

 About the ROW_NUMBER issue, I'll try to explain it better. GDAL only knows
 about "blocks" of data. When you create a new GDALDataset, you can say "my
 raster data have x pixels width and y pixels height, and is blocked. Each
 block has n pixels width and m pixels height". Then, GDAL core calculates
 how many ReadBlock calls needs. In each call, x and y offset are provided,
 based in the calculated number of blocks and the raster data size.

 It's driver's responsibility to match that offsets with one raster block.
 I can't use "rid" because I don't know it offset (0, 0) matches the raster
 block with rid 0, and so on. I'm using that offset (0, 0) matches the
 raster block that starts in pixel 0, 0. With the georeference information
 and a spatial query, I can get the raster data block.

 Of course, I am assuming all the raster blocks have the same dimensions,
 and this is not a requisite. The driver must deal with this problem too.

 About raster_columns, not, the driver doesn't use it.

-- 
Ticket URL: <http://trac.osgeo.org/postgis/ticket/497#comment:11>
PostGIS <http://trac.osgeo.org/postgis/>
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.