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

 Pierre,
 I think I'm closer to your thinking that Jorge's.  What I thought Jorge
 was saying was that he has to do an individual call for each block of data
 which I argue is way better than what he is actually doing with that ugly
 metadata call.

 My assumption how this worked which I'm beginning to think I might be
 wrong is you should never have to do an ST_Extent of the whole table.
 Pierre an extent of a million record table ain't that fast either.


 The way I envisioned how images were rendered in GDAL was

 1) You request for the bounding box of you want.  If you don't then it
 would do an extent of the whole table or (if you did a filter, the extent
 of your where clause).

 e.g. Lets say I have a town with town_id = 1 that I want data for then

 SELECT ST_Extent(rast) from raster_table where town_id = 1

 should be sufficient.

 As Pierre said I would assume at the very least the srid of all the
 rasters were the same.

 So I could even do -- though it looks yuckier -- probably much faste

 SELECT ST_Extent(rast), (foo.md).* FROM raster_table CROSS JOIN
 (SELECT (ST_MetaData(rast)) As md fROM raster_table WHERE town_id =1 LIMIT
 1) As foo
 where town_id = 1


 Knowing the width/height of each raster and srid and extent of the rasters
 I'm asking for are the same would be sufficient to build the structure of
 the GDALDataset to populate with my rasters

 2) Then you do the call for the rasters.  My understanding is that while
 you could do this as a single call (since each raster has its meta data),
 Jorge has to do two calls because the first call needs to create the
 GDALDataset local memory table to hold the blocks and needs to know the
 extent of the blocks, and the second call does a call for each block.

 I think what he is saying is that is a separate call for each rid.  Which
 is actually fine and really not where I'm seeing the time spent. The pain
 I see is the meta data call.

 3) It woulds sequential add the tiles and them clip to the extent of the
 area that was asked for.  Possibly doing a query for each rid (which is
 may not be that slow  because I figure for a good size -- you may do 24
 calls -- I do 1000 calls of stuff in less than a second (granted these
 will be heavier))


 What I was arguing which maybe it was lost, is that in modern web mapping,
 when you need to pull raster, and you have a 600x800 or whatever screen --
 you rarely ask for a 600x800 raster.

 What the javascript (e.g. OpenLayers) does is says -- I want to chop this
 up into
 (my mastery of elemental math is really bad so bare with me I can only
 deal with as , bs and xs)

 Okay it will say -- I need to make 24 calls of 200x400 size rasters (some
 are buffered calls not shown on the screen and some are loaded) -- to give
 a seamless slippery map feel.

 So what ends up happening is that meta data call you have gets called 24
 times and in some(I don't even have any raster data in that location).  If
 I did a bounding query it would be fast, but doing an extent of a 1
 million record table is really slow.  It really isn't cacheable because
 its not done as a single call with (what PostgreSQL would consider static
 data).

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