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

[PostGIS]

#2217: [raster] ST_Binary semantic discrepancy
---------------------+------------------------------------------------------
 Reporter:  mloskot  |       Owner:  dustymugs
     Type:  defect   |      Status:  new      
 Priority:  medium   |   Milestone:           
Component:  raster   |     Version:  trunk    
 Keywords:           |  
---------------------+------------------------------------------------------
 Originally posted to postgis-devel in [http://lists.osgeo.org/pipermail
 /postgis-devel/2013-February/023244.html ST_Binary semantic] thread,
 copied below.


 Currently (SVN trunk), ST_Binary manifests dual nature, depending on in-db
 or out-db storage of raster data.

  * For in-db, ST_Binary returns complete blob with raster data in
 [http://svn.osgeo.org/postgis/spike/wktraster/doc/RFC2-WellKnownBinaryFormat
 WKB format].
  * For out-db, ST_Binary returns the WKB header followed by local file
 path.

 Assuming the WKB format is canonical representation, this ST_Binary
 manifests valid behaviour.

 However, in the out-db case and from usability point of view, transporting
 local filesystem path does not make much sense.

 I would argue, that canonical representation of WKB doesn't necessarily
 have to match ST_AsBinary output. It seems, currently we have made mistake
 in the fundamental behaviour.

 Quick discussion with Regina, Sandro and Even on IRC confirms this
 argument is valid and common sense would suggest to most users that
 ST_Binary should output the same raster data, regardless storage mode on
 the server side.


 Regina also commented that correction may or will potentially affect
 current users.
 {{{
 <robe2>proposal adversely affects prior backup and restore behavior
 <robe2>Well the good thing is that I don't think too many people are
 using out db in 2.0  (they might be using raster though).
 2.1 has much more robust outdb
 <robe2> So I think if we can catch it in 2.1 (even if it breaks
 out-db backward compatibility), it might be okay
 <robe2> 3rd party readers are the MOST important folks to satisfy in my
 mind.
 Because if you guys have difficulty supporting out of the box, no one will
 use it
 <robe2> well GDAL a lot of third parties use indirectly so that goes
 without saying
 <robe2> mloskot: anyrate like I said I think given we didn't really test
 2.0
 out db and I have a feeling its pretty broken so as long as the change
 doesn't
 affect in db, we'll be fine even if breaking for out db
 <robe2> I mean in 2.1 (doing it in 2.1)
 }}}

 The choice between affecting current users of out-db raster storage (are
 there many?) and correcting API for correctness adn consistency in future
 uses is a difficult decision. Let's figure out how to handle it, please.

-- 
Ticket URL: <http://trac.osgeo.org/postgis/ticket/2217>
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.