[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):

 Replying to [comment:7 robe]:

 > On inspecting the queries it seems to be doing some very intensive
 stupid things, but it does also do make box queries but using ~ instead of
 && which we were planning on deprecating and irradicating.
 >
 {{{
 SELECT rid, rast FROM aerials.o_2_boston WHERE rast ~
 ST_SETSRID(ST_makebox2d(st_point(225866,892151),
 st_point(225926,892211)),26986);
 }}}

 That query is the most important thing to change in the driver, IMHO. GDAL
 drivers try to read data blocks in a "smart" way (and that's not smart, I
 know. It's very slow). The GDAL API provides a RasterBlock function (for
 blocked rasters) and a more generic RasterIO function, harder to
 implement, but more flexible. The PostGIS Raster driver was built on the
 ReadBlock function, choosing blocks of the same size of the one you
 specify with -k option in raster2pgsql. So, basically, each call to
 ReadBlock fetches one database row.

 And which row? As input parameters, you have 2 integers (nXBlockOff,
 nYBlockOff). You have to transform them into a specific database row. In
 the simplest case, is reasonable to suppose the (nXBlockOff = 0,
 nYBlockOff = 0) block will match the first raster block in the table, but
 as each raster table row really is a separated raster, you can't ensure
 that. The "mode" can tell the driver the expected arrangement for this
 case is "ONE_RASTER_PER_BLOCK" or "ONE_RASTER_PER_TABLE", and the simplest
 case is an specific case of the last one. I should use a smarter query in
 that case (the 0,0 block matches the row with rid = 0, and so on...)

 Anyway, one server round per readblock call is a really slow way to fetch
 the data. I think I need to implement my own RasterIO function, to solve
 this. And yet, the other related problem to solve is: how to fetch the
 data? One server round per block (table row) is slow, but how safe is to
 suppose a bunch of rows are arranged along a grid? You need to get each
 block's georeference information to be sure. And that's slow.

 Comments welcome. And if I'm talking non-sense, please let me know.[[BR]]


 >
 >
 {{{
 select (foo.md).*, foo.rid from (select rid, st_metadata(rast) as md
 from aerials.o_2_boston) as foo
 }}}
 >
 > why does it need to pull all the meta data for the whole table?  I'll do
 some more logging to make sure its not just that the query is being cut
 off and I'm not seeing the whole thing.
 >

 No, you don't need more logging. This query is used to fill the
 GDALDataset properties with the raster data. With "mode = 2", you're in
 ONE_RASTER_PER_TABLE mode. So, all the table will be considered as a
 raster and will match one single GDALDataset object.

 Anyway, I should use "DISTINCT" here, to detect if all the raster rows
 have the same srid and snap to the same grid. I'll change it.


 > I'm using a couple of days old GDAL trunk with mapserver I believe.
 >
 >

 That's the last version of GDAL driver. OK.

-- 
Ticket URL: <http://trac.osgeo.org/postgis/ticket/497#comment:8>
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.