[postgis-devel] Some thoughts about PostGIS Raster I'd like to share

[Jorge Arévalo]

El martes 4 de junio de 2013 a las 18:41, Paul Ramsey escribió:
> Writing this kind of information to the metadata assumes a "bitbucket" use case, where the primary data manipulation step is load/unload. I'd hate to live in that kind of world.

I understand. Agree. I just present it as an option, to some use cases.
  
>  
>  
> Could a stupider driver do better, by ripping all the candidate data out into memory and then assembling the appropriate metadata there before writing down to disk? Basically accept a memory-bound limitation as a trade-off for flexibility?
>  
Yes. I'm doing something like that right now. I was just looking for something to make it faster.  

> P.  
>  
> --  
> Paul Ramsey
> http://cleverelephant.ca
> http://postgis.net
>  
>  
> On Tuesday, June 4, 2013 at 9:19 AM, Jorge Arévalo wrote:
>  
> > Hello everyone,  
> >  
> > I'm making some improvements to GDAL PostGIS Raster driver, based on a use case similar to this: http://trac.osgeo.org/gdal/ticket/5046
> >  
> > To add more context, the raster objects all have different dimensions and pixel sizes. At high level, a PostGIS Raster table is very similar to a VRT dataset: a bunch of independent raster objects. I used VRT driver for that reason, and now, I'm directly inheriting the driver's code from it. And that made me think about PostGIS Raster itself.
> >  
> > When you construct a VRT file from several sources (like gdalbuildvrt does: http://www.gdal.org/gdalbuildvrt.html), there are some useful information present in the file that is written at build-time. I'm talking about rasterXSize and rasterYSize, or GeoTransform array.
> >  
> > In case of PostGIS Raster, you simply doesn't have that information. It wasn't created that way. So, if you want to know the size of a bunch of different PostGIS Raster objects forming a whole coverage, you need to calculate it. If you want to know the scaling between geometric spatial coordinates and pixel, you need to calculate it. At the end, to read the PostGIS Raster data in the "GDAL way", you need to make some calculations that require scanning the whole table.  
> >  
> > You can make some rough estimates (we actually do it). For example, you can make an estimation of the pixel size, or the scale, using a limited amount of PostGIS Raster objects, to avoid scanning all of them. You can even solve the problem of storing PostGIS Raster objects with different SRIDs in the same table, if you want them to form a dataset. But, at some point, you will need to scan the whole table just to calculate some general properties.
> >  
> > The VRT driver solves this because, as said, those properties are written in the VRT file at creation time. I don't know if you think this is an unapproachable task, or it doesn't fit the PostGIS Raster principles. But, would you consider the option of adding some additional metadata to raster_columns view during raster load?
> >  
> > For example, about scale_x: "This is only available if all tiles in the raster column have the same scale_x and this constraint is applied.". What about allowing the user to specify an strategy to calculate this, even when all tiles have different scale_x values? Same applies to scale_y. And pixel height and width. Something like the '-resolution' flag in gdalbuildvrt.
> >  
> > By having this information stored in raster_columns catalog, you'd save the clients from calculating it by themselves. This is a kind of blocking problem with GDAL driver.  
> >  
> > Of course, if you decide this could be an interesting feature to implement, I would be happy to help.  
> >  
> > Anyway, many thanks for your time.  
> >  
> > --  
> > Jorge Arevalo
> > Freelance developer
> >  
> > http://www.krop.com/jorgearevalo
> > http://about.me/jorgeas80
> >  
> > Enviado con Sparrow (http://www.sparrowmailapp.com/?sig)
> >  
> >  
> > _______________________________________________
> > postgis-devel mailing list
> > postgis-devel at lists.osgeo.org (mailto:postgis-devel at lists.osgeo.org)
> > http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-devel
>  
>  
>  
>  
>  
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org (mailto:postgis-devel at lists.osgeo.org)
> http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-devel