[postgis-devel] [raster] Paths local to server

[Pierre Racine]

And eliminate ST_BandPath...

> -----Original Message-----
> From: postgis-devel-bounces at lists.osgeo.org [mailto:postgis-devel-
> bounces at lists.osgeo.org] On Behalf Of Bborie Park
> Sent: Thursday, February 28, 2013 4:12 PM
> To: PostGIS Development Discussion
> Subject: Re: [postgis-devel] [raster] Paths local to server
> 
> On Thu, Feb 28, 2013 at 1:09 PM, Mateusz Loskot <mateusz at loskot.net> wrote:
> > On 28 February 2013 21:01, Bborie Park <dustymugs at gmail.com> wrote:
> >> On Thu, Feb 28, 2013 at 12:58 PM, Mateusz Loskot <mateusz at loskot.net>
> wrote:
> >>>
> >>> On the course of discussion about ST_AsBinary binary [1],
> >>> it's been revealed that local paths play important role as
> >>> part of public protocol and API in PostGIS Raster.
> >>>
> >>> If that is true, then this is a mistake and design flaw.
> >>> The WKB format in RFC2 does not consider public API
> >>> and Sandro explained to me it does not thorough consider
> >>> out-db storage mode.
> >>> It was clear to me from the very beginning, that the isOffline flag
> >>> is for internal use only, so we can optimise parts of internal
> >>> implementation.
> >>>
> >>> Existence of utility functions like ST_BandPath is not enough to
> >>> support further spread this mistake onto other, more crucial,
> >>> parts of the SQL API.
> >>>
> >>> I'd just like to confirm if this 'local path' madness is going to settle
> >>> for good in PostGIS Raster API.
> >>>
> >>> [1] trac.osgeo.org/postgis/ticket/2217
> >>
> >>
> >> I think the problem really is that the WKB format is flawed.
> >
> > Flawed may be unfair, as the first part of it is fine and well-defined,
> > I'd say it this way (as discussed on #postgis):
> >
> > <mloskot> There apparently is empty page left in RFC2 and some things
> > are not complete there. Later, we took this as completed work, without
> > reflection
> > <dustymugs> yep
> >
> > And that is exactly what Sandro seems to confirm as well.
> >
> >> That format (as adopted) doesn't work for in-db versus out-db.  WKB
> >> shouldn't care if it is in-db vs out-db. Just that it provides a
> >> consistent output where band data is provided.
> >
> >
> > Best regards,
> > --
> > Mateusz Loskot, http://mateusz.loskot.net
> 
> True, "flawed" might be a bit harsh.  Incomplete would be a better
> word choice.  We need to do away with the entire in-db and out-db
> notion and just return the pixel values.
> 
> -bborie
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-devel