id summary reporter owner description type status priority milestone component version resolution keywords cc 2217 [raster] ST_AsBinary semantic discrepancy mloskot Bborie Park "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. {{{ proposal adversely affects prior backup and restore behavior 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 So I think if we can catch it in 2.1 (even if it breaks out-db backward compatibility), it might be okay 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 well GDAL a lot of third parties use indirectly so that goes without saying 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 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." defect closed medium PostGIS 2.1.0 raster master fixed history