[postgis-users] raster efficiency

[Denis Rouzaud]

Hi Pierre,

Thanks for your answer.

To compute profile, here is what I do:
Input is a linestring
Initializes raster ID to NULL
I segmentize to the desired length
Force 3D
For all points do:
     Get point in 2d
     If point does not intersect with current raster ID:
         get new raster ID
     Get altitude with ST_Value
     Set current point with 3rd coordinates
ST_3Dlength

Here is the full SQL if you want 
https://github.com/3nids/qWat/blob/0b1ced3781e135d5eb03f5172610fd8889c7ae36/sql/3d.sql
I noticed that searching for the correct raster took time, so that's why 
I keep current raster ID. And having bit tiles, the probability to stay 
on the same raster is quite high.

Also my 14 tiles are 6x9km at 2m, so this is about 3000x4500.

Do you suggest to cut them before with gdal and have something like 1000 
small tiles rather than my 14 big ones?

Thanks

Denis



On 03/30/2012 03:47 PM, Pierre Racine wrote:
>> I found quite to calculate a profile: it takes approx 1-2 secondes to calculate a
>> profile of 4-6 points.
>>
>> Is there any thing that I can do to fasten the process?
> How do you compute your profile?
>
>> What is the best strategy: having more small rasters or a single big one?
> For raster/vector operations, smaller raster tiles (10x10) is generally preferable/faster.
>
> Pierre
> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20120402/a5d1edbb/attachment.html>