[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