So what do you use instead? Your data set is not exactly common (400+ Gb, 24 band doubles (complex data?), overlapping tiles, which are half empty). Is this LiDAR data? What exactly are you trying to visualise?<div><br /><div>We have little issue with postgis raster speed using multi-temporal, multi-frame, all bands Landsat-8, either in-db or out-db. </div><div>Over 100 Gb by now. We prefer out-of-db, because it keeps the raster db of manageable size. We expect it to work up to Terrabyte limits (I am told I should use SciDB beyond that). This works with mounted network disk as well, which is even nicer.</div><div><br /></div><div>GL</div><div><div style="font-family: 'Times New Roman'; font-size: 16px; "><div><br /></div><div><br /></div><div>On 04/17/14, <b class="name">Rémi Cura </b> <remi.cura@gmail.com> wrote:</div><blockquote cite="mid:CAJvUf_se+7kJw5M8fD+Wig3We6nkxVYPrm=odMs7+AZDinJMSA@mail.gmail.com" class="iwcQuote" style="border-left: 1px solid #00F; padding-left: 13px; margin-left: 0;" type="cite"><div class="mimepart text html"><div dir="ltr"><div><div><div><div><div>Hey,<br />from what I tried PostGis Raster is (relatively) slow and not adapted to multi bands<br /></div>(for instance, no way to set multiple bands at once. For my use case this would mean about 300k*0.1sec i.e. about 8 hours at best).<br />
<br /></div>The GDAL driver + QGIS should be considered an experimental function at the moment, <br />because it is still easily broken (and I'm speaking cutting edge gdal + qgis v 2, 2.2, 2.3 on win and linux).<br /></div>
<div>More generaly using QGIS with postgis is easily broken (i restart qgis several dozen times a day)<br /></div><div><br /></div><div>Taking that into consideration, <br /></div>My conclusion is that for the moment there is no incentive to use __in base__ postgis raster, <br />
</div><div>because there is no stable way to access raster from outside base.<br /><br /></div>Sadly in my general use case, this translate to no incentive to use postgis raster at all :-(<br /><br /></div>Cheers,<br />Rémi-C<br /><div>
<div><div><br /><br /></div></div></div></div><div class="gmail_extra"><br /><br /><div class="gmail_quote">2014-04-17 17:43 GMT+02:00 Tumasgiu Rossini <span dir="ltr"><rossini.t@gmail.com <rossini.t@gmail.com>></span>:<br />
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>Remi,<br /><br /></div>I'm interested in the way you handled this problem.<br /></div><div><br />In my opinion, the problem is on the duality of your needs.<br />
</div><div>Out-db is known to be faster for visualisation.<br />
</div><div>In-db is better for analysis.<br /><br /></div><div>So, a compromise should be made Maybe storing each tile per "band type" ? So accessing data from qgis would be less painful ?<br /></div><div><br /></div><div>
<br /></div>
</div><div class="gmail_extra"><br /><br /><div class="gmail_quote">2014-03-10 10:54 GMT+01:00 Rémi Cura <span dir="ltr"><remi.cura@gmail.com <remi.cura@gmail.com>></span>:<br /><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div class="h5">
<div dir="ltr"><div><div><div><div><div><div><div><div><div>Hey Dear List,<br /><br /></div>I would appreciate some advice about the best way to store my raster :<br /><br /></div>1 million tiles,<br /></div>50*50 pixels each (1 m2 or less in real world), around 24 bands (mostly doubles)<br />
</div><div>,in db.<br /></div><div><br /></div><div>About half the pixels are empty, some tiles overlaps, but most are regularly spaced.<br /></div><div><br /></div>I would query it mainly by localisation (intersects), and also based on id of the tile.<br />
<br /></div><div>The use would be fast visualisation with qgis (and latest gdal), interpolation, classification, matching and so.<br /></div><div><br /></div>What is the best strategy?<br /></div>1 table with many lines and indexes, indb,<br />
</div>1 table, out db<br /></div><div>1 table, 1 line<br /></div>multiple tables, heritage?<br /><br /><br /></div><div>Thanks for inputs!<br /></div>Cheers,<br /><br />Rémi-C<br /></div>
<br /></div></div>_______________________________________________<br />
postgis-users mailing list<br />
postgis-users@lists.osgeo.org <postgis-users@lists.osgeo.org><br />
<a href="http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users" target="_blank">http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users</a><br /></blockquote></div><br /></div>
<br />_______________________________________________<br />
postgis-users mailing list<br />
postgis-users@lists.osgeo.org <postgis-users@lists.osgeo.org><br />
<a href="http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users" target="_blank">http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users</a><br /></blockquote></div><br /></div>
</div></blockquote></div></div></div>