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

[Paragon Corporation]

I definitely have use for ST_BandPath so we should keep it.

Especially since ST_Tile for example creates out of db (and if you copy from
one table to another) it is very conceivable you could have a mix of in
database and out of database rasters in the SAME table.  This could be by
accident or intentional.

I haven't tried to but based on my understanding of our design, I can think
of steps to do create this hybrid table creature.

That said as Mat proposed, having ST_AsBinary be consistent between in db
and out db becomes very important, because you don't want to have a
third-party tool relying on ST_Asbinary have to worry about this
implementation detail if we say its for abstracting away this.

As I mentioned to Bborie, as long as our serialized (which backup uses)
keeps paths (and not full), that is all we need.  In fact serialized
definitely has to be different between the two.  I suspect some of the
performance gains I am seeing with out of db in 2.1 is because out db (for
operations that don't need to touch the underlying raster), is much faster
than in db since less memcopy going on I presume.

 My 2cents,
Regina
http://www.postgis.us
http://postgis.net



-----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:25 PM
To: PostGIS Development Discussion
Subject: Re: [postgis-devel] [raster] Paths local to server

On Thu, Feb 28, 2013 at 1:21 PM, Pierre Racine <Pierre.Racine at sbf.ulaval.ca>
wrote:
> And eliminate ST_BandPath...
>

ST_BandPath is fine as it relates to the serialized raster.  For all we
know, people may want it.  For the WKB though (which is supposed to be for
transport), there should not be any distinction between in-db and out-db
bands.  Just bands and pixel values.

I did a check of postgresql dumping for backups and that only dumps raster
information found in the database.  So, users will not need to do a
dump/restore cycle.  I think robe2 might permit us to make this correction
due to that fact.

-bborie
_______________________________________________
postgis-devel mailing list
postgis-devel at lists.osgeo.org
http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-devel