[postgis-tickets] [PostGIS] #2217: [raster] ST_AsBinary semantic discrepancy

PostGIS trac at osgeo.org
Thu Feb 28 11:04:29 PST 2013


#2217: [raster] ST_AsBinary semantic discrepancy
---------------------+------------------------------------------------------
 Reporter:  mloskot  |       Owner:  dustymugs
     Type:  defect   |      Status:  new      
 Priority:  medium   |   Milestone:           
Component:  raster   |     Version:  trunk    
 Keywords:           |  
---------------------+------------------------------------------------------

Comment(by mloskot):

 Replying to [comment:4 pracine]:
 > Out-db pixel values were planned to be read directly, from the
 filesystem, by the invoking application.

 Pierre, how it was planned? Assuming remote access, such design is
 '''unfeasible''' to realise, unless we consider remote access to
 filesystem directly.

 > Now that we support seamless reading of pixel values for out-db some
 might want to read them seamlessly through the db.

 It's not now, it has been clear from the very beginning that SQL API will
 allow seemless integration, hasn't it?

 > We could add a boolean option to ST_AsBinary() so it returns the raster
 as if it was in-db. Another option is to have  a general way to make out-
 db rasters in-db: ST_MakeInDB(raster)...

 This is not about making out-db rasters in-db, please don't confused such
 case.

 Simply put, if we keep ST_AsBinary return filesystem path, it will make
 ST_AsBinary effectively useless for out-db mode.

-- 
Ticket URL: <http://trac.osgeo.org/postgis/ticket/2217#comment:9>
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-tickets mailing list