1. SELECT rid, r.fnm, (r.rm).upperleftx As ux, (r.rm).numbands As nb, (r.rbm).*
  2. FROM (
  3. SELECT
  4. rid,
  5. filename AS fnm,
  6. ST_MetaData(rast) As rm,
  7. ST_BandMetaData(rast,1) As rbm
  8. FROM deyu.landsat where rid = 1) As r;
  1. upperleftx | upperlefty | width | height | scalex | scaley | skewx | skewy | srid | numbands
  2. ------------+------------+-------+--------+--------+--------+-------+-------+------+----------
  3. 0 | 0 | 600 | 900 | 1 | -1 | 0 | 0 | 4236 | 1

postgis in-db vs out-db

in-db is where the source raster (tile) is stored in PostgreSQL. out-db only stores metadata describing the source raster in PostgreSQL and any functions in PostGIS will call the source raster files as needed. In my testing, out-db is slower than in-db. As to why out-db is slower, my suspicion is that PostgreSQL is able to cache the in-db data in its shared buffers while out-db requires calling the source file every time. – dustymugsAug 31 ‘12 at 17:12

Use the -R flag when using raster2pgsql to add the raster into PostGIS. The -R flag indicates that the raster will be stored out-of-db. All of the raster analysis functions in PostGIS will work but not the write functions, e.g. set pixel values, add bands. In my limited testing, the performance of out-of-db rasters is slower than in-db.http://postgis.refractions.net/documentation/manual-svn/using_raster.xml.html#RT_Raster_Loader

0 评论  
添加一条新评论