[postgis-tickets] [PostGIS] #2217: [raster] ST_AsBinary semantic discrepancy (was: [raster] ST_Binary semantic discrepancy)

[PostGIS]

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

Old description:

> 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.

New description:

 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_AsBinary manifests dual nature, depending on in-
 db or out-db storage of raster data.

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

 Assuming the WKB format is canonical representation, this ST_AsBinary
 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.

--

Comment(by dustymugs):

 changed ST_Binary to ST_AsBinary...

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