<div dir="ltr"><br><div class="gmail_extra"><br></div><div class="gmail_extra">Hey, thanks for sharing your experience !<br><br></div><div class="gmail_extra"><div class="gmail_quote">2014-04-18 0:54 GMT+02:00 Peter Baumann <span dir="ltr"><<a href="mailto:p.baumann@jacobs-university.de" target="_blank">p.baumann@jacobs-university.de</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><div class="">
<div>On 04/17/2014 08:11 PM, guido lemoine
wrote:<br>
</div>
<blockquote type="cite">
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></div></blockquote></div></div></blockquote><div>Yep , good guess. <br>Postgres + pointcloud seems to work good (I have a 5.4 billion points test database, no problem) to handle lidar, <br>but visualisation within GIS software is an issue. Having a rasterized view could be usefull for this.<br>
</div><div>How course importing millions of points in QGIS is not really an option (it works up to a million if style is not too complex).<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div class=""><blockquote type="cite"><div>
<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 </div>
</div>
</blockquote>
<br></div>
when doing that, give rasdaman a try and compare then. It's
operational on n-D multi-TB objects :)<br>
-Peter<br>
<br></div></blockquote><div>I know PostGIS raster is a powerful tool,<br></div><div>I just say that in-base multi-band raster creation is slow<br></div><div>,any raster processing is slow (need to rewrite entire raster)<br>
</div><div>,image processing options are limited (it could be so cool to plug a good image processing lib like itk or otb)<br></div><div>,accessing in-base raster is still fragile<br></div><div>,Level of Detail strategy are not fully integrated.<br>
</div><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
<blockquote type="cite"><div><div class="h5">
<div>
<div>beyond that). This works with mounted network disk as well,
which is even nicer.</div>
<div><br></div></div></div></div></blockquote></div></blockquote><div>The whole postgres data folder can be put on network disk (with caveat), which is very usefull !<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><blockquote type="cite"><div><div class="h5"><div><div>
</div>
<div>GL</div>
<div>
<div style="font-size:16px">
<div><br>
</div>
<div><br>
</div>
<div>On 04/17/14, <b>Rémi Cura </b>
<a href="mailto:remi.cura@gmail.com" target="_blank"><remi.cura@gmail.com></a> wrote:</div>
<blockquote style="border-left:1px solid #00f;padding-left:13px;margin-left:0" type="cite">
<div>
<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"><<a href="mailto:rossini.t@gmail.com" target="_blank">rossini.t@gmail.com</a>
<a href="mailto:rossini.t@gmail.com" target="_blank"><rossini.t@gmail.com></a>></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"><<a href="mailto:remi.cura@gmail.com" target="_blank">remi.cura@gmail.com</a>
<a href="mailto:remi.cura@gmail.com" target="_blank"><remi.cura@gmail.com></a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div>
<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>
<a href="mailto:postgis-users@lists.osgeo.org" target="_blank">postgis-users@lists.osgeo.org</a>
<a href="mailto:postgis-users@lists.osgeo.org" target="_blank"><postgis-users@lists.osgeo.org></a><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>
<a href="mailto:postgis-users@lists.osgeo.org" target="_blank">postgis-users@lists.osgeo.org</a>
<a href="mailto:postgis-users@lists.osgeo.org" target="_blank"><postgis-users@lists.osgeo.org></a><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>
<br>
<fieldset></fieldset>
<br>
</div></div><pre><div><div class="h5">_______________________________________________
postgis-users mailing list
<a href="mailto:postgis-users@lists.osgeo.org" target="_blank">postgis-users@lists.osgeo.org</a>
</div></div><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></pre><span class="HOEnZb"><font color="#888888">
</font></span></blockquote><span class="HOEnZb"><font color="#888888">
<br>
<pre cols="80">--
Dr. Peter Baumann
- Professor of Computer Science, Jacobs University Bremen
<a href="http://www.faculty.jacobs-university.de/pbaumann" target="_blank">www.faculty.jacobs-university.de/pbaumann</a>
mail: <a href="mailto:p.baumann@jacobs-university.de" target="_blank">p.baumann@jacobs-university.de</a>
tel: <a href="tel:%2B49-421-200-3178" value="+494212003178" target="_blank">+49-421-200-3178</a>, fax: <a href="tel:%2B49-421-200-493178" value="+49421200493178" target="_blank">+49-421-200-493178</a>
- Executive Director, rasdaman GmbH Bremen (HRB 26793)
<a href="http://www.rasdaman.com" target="_blank">www.rasdaman.com</a>, mail: <a href="mailto:baumann@rasdaman.com" target="_blank">baumann@rasdaman.com</a>
tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: <a href="tel:%2B49-173-5837882" value="+491735837882" target="_blank">+49-173-5837882</a>
"Si forte in alienas manus oberraverit hec peregrina epistola incertis ventis dimissa, sed Deo commendata, precamur ut ei reddatur cui soli destinata, nec preripiat quisquam non sibi parata." (mail disclaimer, AD 1083)
</pre>
</font></span></div>
<br>_______________________________________________<br>
postgis-users mailing list<br>
<a href="mailto:postgis-users@lists.osgeo.org">postgis-users@lists.osgeo.org</a><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>