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

PostGIS trac at osgeo.org
Wed Feb 16 08:46:24 PST 2011


#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 pracine):

 1) There is a confusion here with srid. srid have nothing to do with
 regular blocking or irregular blocking. The driver should assume that
 every row is in the same srid. You REALLY don't have to fetch all rows to
 know this. If by bad table design or error one or many raster get in a
 different srid, meaning the georeference would be in different unit or
 just very far from where it should be, then the extent of the whole table
 might be wrong and those rasters certainly will be wrongly geolocated.
 That`s life, we can do nothing againts it and the same happen with a
 geometry table with different srid. We do not support this because it is
 very bad user design... The same idea apply for pixelsize.

 If really we want to support these kind of stupid arrangement (with
 different srid or different pixelsize) later then we will have to have
 really good reason to do so.

 2) There are two ways to know the global extent or a table. a) Fetch the
 raster_column table b) Query the table with ST_Extent

 Method a) is becoming less and less reliable. See ticket #542.

 Method b) is very fast when there is an index on the table (which we
 should also assume since creating a table with many tile without creating
 an index would be foolish)

 3) In mode = 2, the driver should first query the extent with ST_Extent
 and then just query all the tiles accompanied by their respective metadata
 in a unique query

 4) You certainly don't need everything provided by ST_Metadata. You should
 query every metadata item with their respective function. ST_Metadata by
 itself is slow because the whole tile has to be red. If you get metadata
 items while you fetch the tiles it should be much faster since the server
 has to load the tile anyway. It will give you the metadata item for free =
 no time

 5) To know if the table is regularly blocked is another story. From the
 beginning I have been against this concept for reason examplified by
 ticket 542. My point is: Just fetch the tile you need alltogether and burn
 them in your raster buffer using the georeference. If this is not possible
 with RasterBlock, then do it with RasterIO...

 I think we need a clear an detailed specification document for the driver
 that we can discuss on. We haven't got one yet...

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


More information about the postgis-devel mailing list